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6800 Developments 

IBM's recent announcements may (or 
may not) have a major impact on what's 
happening in the office apphance com- 
puter scene, but Hawthorne's progress 
with their 68000 Tiny Giant and their K- 
OS ONE operating system is much more 
exciting. While we may be forced to work 
with IBM's and compatibles because 
that's what our customers are now using, 
the '386 systems which will be designed 
for business will be about as much fun to 
work with as the old mainframes. 

Just as the microcomputers using 8080s 
and 6502s developed into a separate 
market from the mainframes and the 
minis; the micro computer market will 
separate into the business machines which 
will largely replace the mainframes and 
the minis, and something else which is fun 
to work with. In the past, programmers 
and hardware hackers slaved on main- 
frames during the day and then went 
home to get personally involved with their 
computers — even average people 
banged away on Apples® because it was 
fun. 

The large volume of sales is in business 
oriented machines, and as they become 
more 'main frame like' they will also 
become less interesting for individuals. 
People who want to get involved with the 
hardware and the operating system will 
have to turn to something else. Some 
possible contenders are the Apple IIGS® 
and the Atari® , but they lack the flavor 
of the old Apple II + and CP/M systems. 
People will be looking for something 
which is more powerful than the eight bit 
systems, and yet friendly. Something 
where they can modify the operating 
system and design their own add on boar- 
ds. The only answer I see right now is a 
68000 system using Hawthorne's OS 
which comes with the source code. 

Hawthorne has been making steady 
progress expanding their product line with 
items like their new Editor Toolkit, and 
they're working with people on a com- 
munications package, a Forth implemen- 
tation, and possibly a BASIC, but what 
we need is the third party and hacker in- 
volvment we had with the early Apple II. 
If you want to develop code or hardware 
for a 16-bit system where everything in- 



cluding the operating system is under your 
control, you should write to Hawthorne 
for their information package. If enough 
of us get involved we can get a C compiler 
running and perhaps convince Joe to 
produce a board with slots for easy expan- 
sion. Write or call Joe Bartel at Hawthor- 
ne Technology, 8836 S.E. Stark, Por- 
tland, OR 97216 (503) 254-2005, to find 
out what's happening in the 68000 world. 
He'd really be interested in talking with 
anyone who wants to develop a hardware 
or software package for K-OS ONE. 

If you'd like to write an article or a 
column on the 68000, I'd be real in- 
terested in talking with you (even short 
notes and letters will be appreciated). 
Graphics Mania 

Former CP/M users are complaining 
that too many PC/MS DOS utilities u.se 
fancy graphic displays which make them 
unprintable. CP/M users are used to 
using control-P to toggle on the printer 
during an assemble, compile, or 
debugging session in order to generate a 
complete hard copy history of a work 
session, and this does not work with PC 
programs having elaborate graphic 
displays. The question here is whether we 
have impressive graphics or useful infor- 
mation, and I'll vote for having the hard 
copy information I need instead of pretty 
displays which impress the sales people 
and non-technical users. 

I fully agree that there are instances 
where bit-mapped graphics are necessary 
in order to display charts, graphs, 
illustrations, and other non-character type 
material; but I strongly object to being 
forced to look at some designer's idea of 
modern art while working with a character 
oriented programming utility — in fact I 
just won't use them! I fully agree with Joe 
Bartel (see his 68000 section) that if you 
need graphics it should be on a second 
monitor, and if you need multiple win- 
dows they should each be on their own 
monitor instead of many tiny windows on 
one screen. 

Compare these ideas with the former 
idea that everyone should work at a dumb 
terminal attached to the main 
frame — they couldn't understand why 
an individual would want the power of 
our current micros on their desk. Now 



we're saying that people will want 
multiple CPUs and multiple screens in- 
stead of multitasking one one CPU and 
windows on one screen. 

Everyone is welcome to their own 
opinion, and mine is that for character 
oriented work I want a high speed charac- 
ter oriented monitor with no fancy 
graphic borders or other distractions. At 
least the program designers could provide 
a toggle so that the user could select bet- 
ween a plain character and a fancy 
graphics interface. 

This is probably a cultural issue. People 
who were raised watching color cartoons 
on the boob tube, and who are not com- 
fortable reading a book, want to make 
their computer monitors look like the 
Saturday morning funnies. I like reading 
books, and I want my screen to look like a 
book — unless 1 need graphics for 
illustrations or CAD. Even books have 
illustrations where needed, but there is a 
difference between a good novel and a 
comicbook! 



// this doesn 't get someone mad enough 
to write, I'll give up trying to get any 
response. The purpose of this Journal is 
to provide communications, so if you 
have something to say send it on disk or 
hard copy. 



(Continued on page 44) 
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Reader's Feedback 



Chicken-And-Egg Problem — Part One 

I have been long concerned about the 
chicken-and-egg problem with new 
microprocessor chips, and 1 have a 
suggestion which I beheve would aid the 
proliferation of the Series 32000 
microprocessors. Now, I have much 
respect for the Herculean effort that 
National has made in developing the 
32000, so please don't think that I would 
frivilously recommend additional work 
that National should do. 

Thinking about the development of the 
32000 makes me think of a marathon 
bicycle race. In approaching the last hill, 
the front-runners are usually in a pack. 
Suddenly, one cyclist will break from the 
pack and very strenuously apply everlhing 
that he has in an attempt to be the first to 
reach the top of the hill. If he makes it to 
the top of the hill without croaking, he's 
the clear winner; he will sail to the finish 
line with no possibility of the others cat- 
ching up. Since I see National selling those 
very inexpensive 32000 designer's kits, it 
seems to me that National is now attem- 
pting to break from the pack. When the 
cyclist is in the middle of his big effort to 
make good his break, it is likely that the 
legs will send messages to the brain in- 
dicating that something additional is 
needed. Likewise, in order for the 32000 
to really decisively break from the pack, 
something additional is needed. 

Consider the early days of the 8080. 
There were very many people who were 
regular engineers by day and 8080 ex- 
perimenters by night. When the manufac- 
turers began to build products using 
microprocessors, the industry turned into 
a big vacuum cleaner trying to suck up 
everyone who had experience with 
microprocessors. The only people who 
could answer the job ads were those who 
had experimented with microprocessors at 
home at their own expense. I disregard the 
engineers that the various firms extract 
from one another because there is no gain 
in this kind of exchange. Because of the 
availability of these self-taught 
microprocessor users, the 8080/Z80 boom 



was spectacular. Intel is still riding on the 
8080 boom that was given to them by 
amateur experimenters. 

Consider the early days of the 68000. 
For the experimenter, bootstrapping his 
own operating system and assembler was 
too much of an obstacle. Therefore, the 
amateurs stuck to their Z80's although 
they had great lust for the 68000. 
Motorola did nothing to cultivate self- 
taught users; they catered only to OEM's. 
The OEM's built nothing but white 
elephants because there was no supply of 
amateur 68000 users to give the OEM's 
the kind of expertise that they needed. If 
there had been a supply of self-taught 
users of the 68000, IBM could have used 
the 68000 in the first PC. If Motorola had 
issued a simple public domain operating 
system and assembler for the 68000 the 
same day that they introduced the chip, it 
is possible and even probable that we 
would not see any Intel segmented 
microprocessors in any personal com- 
puters today. For the first time in the life 
of the 68000, there is now an economical 
($50) operating system with an assembler 
available to allow amateurs to begin work 
with the 68000. It's not from Motorola; 
it's from Hawthorne Technology. 

Consider the present days of the 32000. 
National sells some very nice development 
tools, but they are all for OEM's. There is 
nothing for amateurs. The OEM's are 
producing some exceptionally wonderful 
white elephants, but nothing that is apt to 
proliferate enough to give the 32000 the 
widespread usage that it deserves. There is 
no supply of experienced 32000 en- 
thusiasts to give the OEM's the kind of 
expertise that they need. The designer's 
kits go a long way toward putting the 
32000 in the hands of passionate ex- 
perimenters, but in this day and age the 
chip set is not enough. There is a grass 
roots 32000 interest group germinating in 
the readership of Micro Cornucopia 
Magazine, and I have corresponded with a 
number of amateurs who are fabricating 
their own experimental 32000 board. It is 
excruciatingly painful for me to think of 



the great duplication of effort as each of 
these experimenters attempts to bootstrap 
his own operating system and assembler. 
The assembler in the Tiny Development 
System that comes with the designer's kit 
is nice but is not sufficient for the task of 
bootstrapping an operating system. I have 
been attempting to popularize the 32000 
by giving away all the 32000 code that I 
write. I'm in the middle of writing 32HL 
(32000 hacker's language), which is a 
stand alone combination of operating 
system, assembler, high level language, 
and editor. I plan to give it away to the 
public domain even though I am not gain- 
fully employed. I have temporarily given 
up this effort because the cross assembler 
that I purchased from 2500AD was no 
good. 

Here is my suggestion: National should 
issue a public domain simple single-user 
operating system (with assembler) for the 
32000 which any arbitrary experimenter 
can port to his own unique 32000 board. 
Such an operating system should be at 
least as simple as CPM 2.2 and must have 
a customizable BIOS similar to that of 
CPM 2.2. Note that the customizable 
nature of CPM is in part responsible for 
the 8080/Z80 boom. Each experimenter 
can develop his own BIOS using the Tiny 
Development System. With this kind of 
system in the hands of 32000-loving ex- 
perimenters, there is no way that the 
32000 could avoid being a smash hit. 

Neil R. Koozer 



Clikken<And-Eu Problem — Part Two 

I think I've finally figured out how to 
solve the chicken-and-egg problems with 
the 32000. It involves re-writing my 432 
system with a different foundation. The 
new version will start out as an assembler 
so that it will be able to compile itself in 
one quick pass at any stage of its 
development. It should progress 
something Ike this: 

I . Create an NS32 native version of the 
cross assembler Z32. It will call Z80 



The Computer Journal / Issue #29 



CP/M for nic I/O. 

r Add high-level keywords such as IF, 
ELSE, REPEAT, UNTIL, etc. At this 
poini n's a language compiler that accepts 
either high-level syntax or assembly syntax 
in an> statement. After this, any new 
features can be written in high level 
language, and pre-existing features could 
be changed to high level language. 

3. Add an outer loop which accepts 
keyboard input, compiles it, and executes 
it. This loop creates the features of com- 
mand processor, high-level language in- 
terpreter, and assembly-language inter- 
preter. It will return even after stack- 
altering statements are executed. The 
DOS commands (PIP, DIR, etc.) will be 
in the language vocabulary, so they can be 
executed from the keyboard or from 
programs. Therefore, no batch processor 
will be needed. Nothing like ARGC or 
ARGV will be needed because the 
keyboard invocation of a program will be 
treated like a normal function call with a 
normal parameter list. 

4. Since an assembly-language inter- 
preter is almost a debug monitor, simply 
add the few remaining commands to make 
it a full debug monitor. These will include 
disassembler, one-key single stepping, 
one-key trace-through-call, and auto- 



updating display of registers and chosen 
memory locations. 

5. Allow string variables to be com- 
piled the same as include files so that 
string variables could be used as keyboard 
macros, small batch files, etc. 

6. Integrate a screen-oriented editor in- 
to the outer loop. The same editor would 
be used to edit command lines and source 
files. The command line would be stored 
so it could be re-edited and re-executed 
any number of times. 

7. Add or change enough features to 
allow any arbitrary experimenter to port 
this code to his unique 32000 computer. 

Because of the speed of this compiler 
there may be no need to store any com- 
piled programs, but just store the source 
code. At any time, an old version of the 
(compiled) system would be in EPROM. 
Upon power-up or reset, it would check 
for an 'autoexec' file, which could have 
instructions to compile the current version 
of the operating system and to execute it. 
This operation would be finished long 
before the CRT lights up. To install a new 
version of any module, simply put the new 
source code for that module on the boot 
disk and reset. All library modules for the 
high-level language could be included as 
well since replacement is so easy. 



Whenever the EPROM version becomes 
inadequate for compiling the current ver- 
sion, a new EPROM is burned. 

At the end of any compilation, the 
symbol table would contain the symbols 
corresponding to any global variables or 
procedures so that they can be used 
manually or used by any subsequently 
compiled program. With this scheme, any 
program could make symbolic reference 
to functions in the BIOS, BDOS, and 
library without the use of jump tables, 
link tables, or external addressing mode. 
A BIOS jump table would be temporarily 
used in a distribution copy until the user 
has the system running. 

Neil R. Koozer 



HD64180 

In issue #27 you published a article 
about the HD64180. Since then Hitachi 
has released, or is about to release, the Z 
mask version which is more tolerant of 
ZSOperipherials. 

I am running a Xerox 820-11 with ZC- 
PR-2. My Z80 is resetting the system once 
in a short while after a cold start. Rather 
than buying a new Z80 I would like to 

(Continued on page 35) 





A fast 1 megabyte RAM disk 

for your AMPRO Z80 Little Board! 

Fast RAM workspace greatly speeds up disk-intensive 
operations like wordprocessing, database access, and 
program development. 

• 5 "5 ■ 5 '5 printed circuit board plugs into your AMPRO Z80 socket 

• Add standard 256K RAM chips (or up to 1 megabyte of extended RAM 

• BIOS resident MDISK driver software enables the extended RAM to be used as 
a solid state disk drive complete with system track lor instant warm boots 

• Drive' software supplied as readv-to-instalt BIOS nex files for several common 
svslen-, configurations Source code for BIOS driver insens also included 

• Includes utilities for boot-time configuration ana ertended RAM testing 

• Requires 5vdc at 60 amp via standard disk anve power connector 

• tittle Board must be modified to replace the GJi* RAM cnips with sockets a^c 
to add one jumper Complete instructions inciudeo 

MDISK (Ok RAM supplied), including complete manual and 
software disk, only S149 plus S5 shipping and handling 
California residents add 6% sales tax Checks. COD. MO 
accepted 



21460 Bear Creek Road. Los Gatos. CA 95030 



We have CP/M software 

NewWord — the better word processor 

includes WORD plus by Oasis! 

CP/M 80 $69 

SuperSort — original sorting program 

CP/M or MSDOS $85 

Turbo Pascal — version 3.0 

CP/M or PC/MS DOS $45 

Turbo Toolbox for CP/M or MS DOS $39 

The above items are limited to stock on hand. 

C/80 Compiler $45 

DateStamper — adds date and time to your CP/M 
directory. $45 

8' SSSD disks, per box of 1 $5 

Hardware and software for Heath/Zenith computers. 

Add $4 per order for shipping and handling 
Terms: Check or Money Order — Visa/MC — COD 
California residents add 6% tax 
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213 Teri Sue Lane 



Buellton, CA 93427 
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Better Software Filter Design 

Writing Pipeable User Friendly Programs 

by Kevin Lacobie, University of Texas Medical Branch 



Summary: One of the more powerful features of the UNIX 
operating system is piping, which allows the output of one 
program to be immediately sent as the input to another program. 
While MS-DOS has the piping feature, most programs written in 
this system are not directly compatible with piping. The reason is 
because of a conflict between terse 'pipeable' and friendly 
'readable' output, and MS-DOS has chosen a more readable out- 
put, for the perceived casual user of its personal computer 
operating system. A compromise is offered that allows programs 
written under DOS to be 'pipeable', yet still 'user friendly'. 

In computer operating systems supporting input and output 
redirection and piping, the use of filter programs has become 
popular. Output redirection refers to sending output from a 
program to a device or file other than the default, which, for most 
interactive systems, is the user's console. Input redirection is 
similar, taking input for a program from something other than 
the interactive device, the keyboard. Piping refers to the process 
of having the output of one program be the input of another 
program. Filter programs are "programs that read some input, 
perform a simple transformation, and write some output. "(1) 
The UNIX® operating system has become the most noted for its 
use of redirection, piping, and filters. 

For piping and filter programs to be robust, all programs in 
the system must conform to some standards. Namely: 

"The output produced by UNIX programs is in a 
format understood as input by other programs. 
Filterable files contain lines of text, free of decorative 
headers, trailers, or blank lines. Each line is an object of 
interest — a filename, a word, a description ... When 
more information is present for each object, the file is 
still line-by-line, but columnated into fields separated by 
blanks or tabs... "(2) 

Since each program conforms to this, multiple programs can 
be piped together, to transform some input into some interesting 
new output. Given a range of robust filter programs, many dif- 
ferent interesting results can be derived by properly piecing these 
programs together. "This powerful technique allows programs to 
be written as small, compact, onc-purposc-only packages which 
can be used in conjunction with other programs to form more 
complex packages. "(3) Thus, this often results in higher produc- 
tivity, for each time a new result is needed from some input, a new 
program need not be written. 

Interestingly, the MS-DOS* (Microsoft Disk Operating 
System) found on most personal computers supports redirection 
and piping. However, many of its commands do not comply with 
the above standards. This renders filter programs less functional, 
even useless. MS-DOS has not whole-heartedly embraced the ad- 
vantages of the above standards. Interpreting this treatment 
toward the functionality of piping and program interaction leads 
to understanding some of the deficiencies in an operating system 



environment based entirely on the above standards. 

MS-DOS has been largely created from UNIX and CP/M, an 
earlier operating system for microcomputers. Being for personal 
computers, the outputs of most commands are designed for 
usability, or 'user friendliness.' Thus, decorative headers, trailers, 
and blank lines are used. This not only makes for a more attrac- 
tive display, but gives readable information to the user. For 
example, the DIR command gives a list of all files in one subdirec- 
tory on a disk: 

Volume in drive B is KEVIN 
Direccory of B:\ 



ARTICLE2 4138 


U-14-86 


l:06p 


ARTICLE 2408 


11-13-86 


l:33p 


WORDS USE 66 


12-01-86 


5:33p 


WORDS <DIR> 


11-13-86 


11:58a 


ARTICLE3 1621 


11-17-86 


10:42a 


UNIXPC 3263 


12-18-86 


3:15p 


CAPS SCR 335 


12-01-86 


2:12p 


CAPS COM 56 


12-01-86 


2:l2p 


COMMUTE <DiR> 


12-18-86 


3:20p 


FILTERS 6662 


12-19-86 


12:12p 


U File(s) 222208 bytes free 



The output from DIR is indeed readable. However, it is 
nearly useless for filter programs. A user may want to sort the in- 
formation by date, for example. A sort program could sort each 
line from the output of DIR, but it would sort the header lines 
and the summary lines in its output, thus not producing the expec- 
ted output. 

A typical UNIX command, when invoked, gives only a terse 
response. As pointed out above, this terse response is excellent for 
the standard, for another program could use its response as input. 
However, for a user, most "UNIX tools tend to be terse to the 
point of unhelpfuiness."(4) For example, WC is the word count 
program. It will count the number of words in a normal text file. 
Yet, when invoked, it will respond with a line similar to: 

59 199 2029 file 

The output's meaning is unintuitive to the user. Only if the 
user remembers this command, or if header information is prin- 
ted, will it be known that 'file' contains 59 lines, 199 words, and 
2029 characters. 

A typical DOS command might give such header infor- 
mation. This has proved very helpful for users, who on personal 
computers tend to be casual users. Thus, very few programs in 
MS-DOS have been written to the standard of filter programs. It 
can be argued that this has resulted in the loss of some fun- 
ctionality, as a new program must be written for every new task. 
In summary, DOS has given up the advantages of the pipe, in 
favor of more user readable output. 
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Certainly, some compromise between the standards for good 
filter programs, which leads to well-integrated tools, and more 
friendly output is desired. In "The Critique of UNIX," such a 
compromise has been described. A high level construct should be 
available for a program to know whether "it is being called as 
'stand-alone' or part of a chain of programs. "(5) With this con- 
struct, programs can, without much effort, take on a very dif- 
ferent shape. If the input was not piped in, then the program can 
prompt the user for needed information. If the programs's output 
is not to be piped, then header information, more proper spacing, 
and summary information can be printed. However, if in a pipe, a 
program can output in the terse, single line per object format 
famous in UNIX programs. Now, the 'best of both worlds' is 
permitted. 

A simple example below shows how a program would be 
written with this construct: 



extern Inc standalone () ; 

mainO 

{ 

int _standalone,suint ; 

_standalone = standaloneC) ; 
if (_standalone) 

printfC'PROCESSING HEADER\n") ; 
doProcessingO ; 
if (_standalone) 

printf ("SIMMARY DATA: Zd\n",sumt) ; 
} 



The only responsibility of DoProcessingO is to output infor- 
mation one line per object. Only if in a standalone mode will 
header and summary information be printed, and this is handled 
by mainO- 

Standalone can be easily added to MS-DOS. Since version 2, 
a DOS function call is available which allows the program to in- 
terrogate device information. With this function call, standard 
output can be interrogated to see if it is a character or block 
device. Character devices are such entities as printers and con- 
soles, while block devices are for storage of files. Since piping is 
done through temporary files, it suffices to determine if the stan- 
dard output is a character device or not, to determine if it is part 
of a pipe or not. 

Standalone can be created as a function utilizing this 
method. Below is shown the function in 'C, with a standard 
library call to make a DOS call. 

Ilnclude <dos.h> 
Int standaloneO 



R£GS regs ; 
Int flag ; 



regs. ax - 0x4400 ; /* DOS funct# for lOCTL */ 

regs.bx - 1 ; /* DOS # for standard output */ 

flag - lntdos(&regE,&regs) ; 
/♦check Bit 7 to determine if character device*/ 

regs.dx &> 0x80 ; 

return (regs.dx "■ 0x80) ; 
} 

/* 

See latest version of DOS Technical Reference 
Manual, under the chapter "DOS Interrupts and 
Function Calls", for the description of function 
call 44 Hex, "1/0 Control for Devices (IQCTL)" 



Similarly, lnAlone() can be written to lest whether the 
program's input is coming from the standard input device, or was 
redirected or piped. InAlone can be used to determine the 
necessity of prompts to the user. The only difference in the above 
code for 'inalone' is <C> regs.bx = 0<C> , to signify the DOS 
number for standard input. 

With these constructs, programs should conform to some 
new standards. Namely, the filter program standards mentioned 
above should be used, but when 'standalone' (and only when 
'standalone'), a program should print a header describing the 
output, appropriate blank lines and pagination, a header 
describing each column of information, and summaries giving 
totals or other relevant information about the collection of objec- 
ts that the program processes. 

With this in mind, LS.C (Listing 1) has been written to give 
an example of the use of 'standalone'. LS is also a useful program 
for DOS systems. First, it can display all that DOS knows about a 
file. Secondly, it is able to hst files in all subdirectories in the 
hierarchical file structure that DOS has had since version 2. 

The syntax for LS is: 

LS [searchpatternj 1/A{A|R1D |H} ] [/¥] [/D] [/T] [/Sj 

'Searchpattern' may contain drive and directory infor- 
mation. Without any flags, LS will display only file names. Ad- 
ding flags /A (Archive), /F (File size), /D (Date), and/or /T 
(Time) will display more information about each file. Qualifying 
the /A flag will list only files with the qualified attribute(s) (A for 
Archive, R for Read-only, D for Directories, and H for Hidden 
(and System) files). Adding /S will allow LS to display files under 
all subdirectories of the specified search pattern. 

If standalone, LS will output in the following format: 

DOS FILE INFORMATION 
DIRECTORY: d:\path 



FILEl sss dd/mm/yy hh:nini Attr 

FILE2 



II II 



DIRECTORY: d:\path\subpath 
F1LE3 " 

If in a pipe, however, the output is only one line per file, 
the following format: 



m 



d:\path\FILEi sss dd/mm/yy hh:i 
d:\path\FILE2 



Attr 



The latter output is more useful for other programs to per- 
form sorting, selecting, or selective file processing, and be able to 
access files, regardless of which subdirectories they are in. 

As another example, InAloneO is used in the the ParseCom- 
mand() procedure (Listing 2), which can be used to add flexibility 
to normal filter programs. ParseCommand will look on the com- 
mand line, or prompt the user, whenever it determines that the 
input is not being redirected. This allows a program to be called in 
one of three ways: either as a filter, with syntax: program < infile 
> outfile; as a command, with syntax: program infile outfile; or 
as a prompted command by entering just program, and the 
program will prompt the user. The trick is in the fact that 'stdin', 
the standard input, can be closed and reopened to a program sup- 
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plied filename. With ParseCommandO, a programmer can write 
the main program operating on only the standard input and out- 
put, and not worry at all about the I/O. For example: 



main(argc,argv) 
inc argc ; 
char *argvl J ; 



char c ; 

ParseCommand(argc,argv) ; 
while (geCs(scr) != EOF) 
( 
/* To be whatever the filter processes */ 

Process(,str ; ; 

puts(str) ; 
} 

Adding ParseCommand to a filter program adds three user 
interfaces to the same program. First, it can be a filter program, 
to be used in pipes. Second, it performs like a command, with the 
user specifying files on the command line. Last, it presents a 
prompt interface, for the more casual users who only know the 
name of the program. ParseCommand can be different for each 
application, as it may need to parse flags or options on the com- 
mand line, or give additional prompts to the user, depending 
upon the application. ParseCommand could easily present a for- 
ms interface, or a 'point-and-shoot' method to choose files. The 



point is that the main application need not deal with these details. 
All the main applications needs to operate on is what it thinks to 
be the standard input and output. 

The UNIX system, popularized filter programs. It is even 
conjectured that the redirection and piping features are the cen- 
tral features of UNIX. While MS-DOS has taken many of the 
same features from UNIX, its built-in commands and programs 
do not conform to the same standards, rendering piping less fun- 
ctionality. DOS does this to obtain the advantage of more 
readable, thus more useful to the casual user, output from com- 
mands. The simple functions standalone and inalone, which use 
only a single DOS call, solve the problem of filter programs being 
too terse, while maintaining their functionality. Users writing 
their own programs, and programmers creating public domain 
and commercial software are encouraged to incorporate these 
functions in their programs, so their programs can be used in 
piping and for casual users. 

References 

(I) Brian W. Kernighan & Rob Pike, Unix Programming En- 
vironment, (Prentice-Hall, New Jersey: 1984), p. 101 

(2),ibid.,pA30. 

(3) Gordon Blair, Jon Malone, & John Mariani, "A Critique 
of Unix" Software- Practice and Experience, V.15, #12 (Decem- 
ber 1985), p. 1132. 

(4)ibid.,pAU5. 

(5) ibid., p.l\32. 



Listing 2 Continued 

case 2 : 

strcpy(f ilename.argvll ] ) ; 



case 1 



break 

fprintfCstderr, "Which file to convert? ") ; 
if (strlen(gets(f llename)) ~ 0) 

exit(l) ; 
if (StandAloneO) 
{ 

pfrintfCstderr, "Output to where? ") ; 
gets(file2} ; 
} 

break ; 
default : /* argc > 3 */ 

fprintfCstderr, "ERROR. Usage: %a file newf ile\n",prognaae); 
f printf (stderr," or Xe <file >newf ile\n",prognaBe; 
exlt(l) ; 
) 

if (freopen(filename,"r",8tdin) — NULL) 
{ 

frplntf( stderr, "Cannot open 'Is' \n",f ilenaae) ; 
exlt(l) ; 
) 
else 

if (strlea(flle2) I- 0) 

f reop«a(f ile2,"w",stdout) ; 







Own The 
Source Code 

We have C source 
code for public domain 
versions of most UNIX 
programming tools. 
Control your environment 
wherever you work! 
Over ICX) volumes... 
Quarterly newsletter. 
C and UNIX Books. 
200 page indexed source 
code directory. 

Write or call 
C Utan' Group 

PC Box 97 
(316)241-1066 
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MDISK 

Add a One Megabyte RAM Disk to Ampro LB. 

by Terry Hazen & J im Cole 



Introduction 

MDISK is a printed circuit board, containing sockets for up 
to 1 megabyte of 256k RAM chips, that plugs into the Z80 socket 
on your AMPRO Z80 Little Board. The MDISK software drivers, 
when added to the AMPRO BIOS source code, enable the Little 
Board to use the additional RAM as a solid state disk drive, com- 
plete with a system track. MDISK utilizes the additional memory 
by swapping 32k pages in and out of the lower 32k of system 
memory while the upper 32k, containing the operating system 
along with the MDISK drivers, remains a stable "global" 
memory segment. 

AMPRO's SYSGEN utility can be used to copy the system 
track from your AMPRO boot disk to the system track on 
MDISK, and the SWAP utility will allow you to make MDISK 
your logical drive A so that very fast warm boots can be made 
from the MDISK system track. The ZCPR3 PATH utility can be 
used to optimize your file search paths for use with MDISK. 

In part one of this series, we will discuss the modifications to 
the Little Board that are required in order to allow the MDISK 
hardware to address and refresh the extended RAM. In part two 
we will cover the software driver routines that are added to the 
AMPRO BIOS in order to enable the extended RAM to emulate a 
disk drive. 

Although MDISK was designed specifically for the Little 
Board, it could probably be used with many other Z80 computers, 
depending on their specific hardware design and the structure of 
their BIOS. At this time, however, MDISK has not been tested 
with machines other than the AMPRO Z80 Little Board. 

Why use a RAM Disk? 

Since Z80 computers only have a 64k memory space to work 
with, many programs use the disk drive a lot to swap program 
overlays in and out of memory. This process can be quite slow, 
especially if you are using floppy drives. The major advantage of 
using a RAM disk as your operating workspace is its greatly in- 
creased speed when you are performing operations requiring a lot 
of disk access, like word processing, program development, or 
database manipulation. Files resident on a RAM disk are accessed 
at memory speed, while accessing files on floppy or hard disks is 
relatively much slower. 

For example, using a 4 mhz Little Board and a %tpi floppy 
disk drive with a 3 ms head stepping rate, the ACOPY file copy 
utility can copy and verify a 100k file to another filename on the 
same disk in about 91 seconds. The same operation on the 
MDISK RAM disk takes about 18 seconds, almost one-fifth the 
time. On the floppy disk drive, WordStar and the same 100k file 
can be loaded and the file ready to edit in about 26 seconds, while 
on MDISK they are ready to go in under 4 seconds! 

Your computer work habits will probably change a lot when 
you have this kind of fast response at your fingertips. When doing 
assembly language programming, for instance, you can modify 



the source code, assemble and test it, and go back and repeat the 
cycle again so quickly that it becomes almost interactive. You can 
also use the ZCPR3 utilities VALIAS and SAK to set up a recur- 
sive ALIAS (that is, an ALIAS that calls itselO to create such a 
cycle, making the process even easier and faster. 

Programs seem to run so fast that it becomes very fast and 
easy, for example, to exit WordStar, run another program or look 
up material in another text file, then go back into WordStar 
almost as quickly as you can write about it. The Little Board isn't 
running any faster, you just aren't waiting around for the disk 
drives to do their work anymore. It is very hard to go back to a 
floppy disk system after using MDISK for a while, and the system 
that seemed perfectly adequate before now seems horribly slow 
and inconvienient. 

The Price of Progress 

Everything has its price, however, and MDISK is no excep- 
tion. Only the later model IB Little Boards have a provision for a 
high speed bus, the SCSI port. SCSI extended RAM boards are 
offered by AMPRO and while they are undoubtedly the easiest 
and most elegant way to obtain Z80 extended RAM, they are 
relatively expensive. We have chosen instead to access the Z80 
directly. Our approach is to remove the Z80 from its socket and 
plug in a printed circuit board containing the required interface 
circuitry, the extended RAM chips, and a new socket for the Z80. 
This approach requires a little hands-on modification of the Little 
Board, but is considerably less expensive and can be used with all 
Z80 Little Boards, even those without SCSI capabilities. 

Since MDISK will contain a number of 256k dynamic RAN 
chips that will replace the 64k chips originally resident on the Lit 
tie Board, you will need to remove the 64k chips from the Littl 
Board, replace at least one of them with a socket, and you wil 
need to add one jumper. A 16 pin ribbon DIP cable from this Lit 
tie Board RAM socket to the MDISK board will allow access tt 
the normal 'RAM BUS' signals on the Little Board so that wt 
don't have to duplicate the circuitry that provides them. If all 8 
RAM chip positions are socketed, the Little Board will operate 
normally when the 8 64k RAM chips and the Z80 are present. 

Another part of the price that must be paid is the suscep- 
tability of the data contained on the RAM disk to problems on the 
AC power line. Since MDISK becomes an integral extension of 
the Little Board, the whole Little Board/MDISK combination, or 
at least the 5 volt power to both boards, must be battery backed- 
up to avoid power outage problems. We have not taken that ap- 
proach at this time, choosing instead to knowingly use the 
MDISK RAM disk as a volatile workspace and making use of 
ALIAS files, archiving (under ZRDOS), and ACOPY to help us 
back up the working material often during the work sessions. This 
approach has worked quite well in practice. 
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Ampro Little Board Modifications 

With care, removing the 8 64k RAM chips on your Little 
Board and replacing them with sockets is not really difficult. If 
you don't have experience with soldering and desoldering on prin- 
ted circuit boards, you might wish to review James O'Connor's 
article, "Repairing and Modifying Printed Circuits" and Bill 
Kibler's column "The Computer Corner," which deals in part 
with removing and replacing ICs. Both articles appear in issue #25 
ofTCJ. 

Removing the RAM Cliips 

The first step is to identify the 8 chips you need to remove. 
They are the 64k RAM chips, and are marked "4164." On the 
Little Board 1 A (the original Little Board), they are chips U21-24 
and U30-33. On the newer Little Board IB (with provisions for 
SCSI), they are chips U19-21 and U30-34. Remove these chips by 
cutting off each chip lead close to the PCB with close cutting 
snips. You can then use a good solder sucker to remove the lead 
and the solder at the same time, provided that the lead is straight 
and the solder sucker is kept clean and clear. When all the leads 
have been successfully removed, check all the holes and clean 
them out with a solder sucker if necessary. 

Adding Socliets 

You will need to add one socket to the Little Board in order 
to access some of the signals needed for RAM control, but as long 
as you need to add one socket, you might as well socket all 8 
positions so that you can have your Little Board work as it did 
originally if necessary. If you wish to only add the one required 
socket, the prefered position is U21 on both the model lA and 
model IB. 

Use good quality 16 pin sockets. Low profile, double-wiping 
sockets that make contact on both sides of the IC leads are 
recommended. Tack all the sockets in place first, soldering only 
the two diagonal corner leads on each socket. Then you can apply 
finger pressure to the socket and re-melt one corner of each socket 
at a time, which will release the socket to seat itself fully. Then 
you can carefully solder the remaining leads. Check for good 
connections and any solder bridges. Clip off the leads close to the 
board if they are too long. 

Adding tlie Jumper 

Add a jumper on the back of the Little Board from pin 1 of 
the RAM socket that you will use for your 16 pin ribbon DIP 
jumper cable (for example, U21 on either the model lA or IB) to 
pin 1 of either of the two 74LS157 multiplexer chips (U20,29 on 
model lA, U22,23 on model IB), whichever is closest. This jum- 
per will extend the multiplexer select line to the MDISK board, 
where it will be used to help generate the extended chip ad- 
dressing. 

Flux Removal 

Use a liberal quantity of flux remover spray to remove all 
residual flux from back of the Little Board, following the direc- 
tions on the can. To avoid problems with the fumes, work out- 
doors if at all possible. When you are done, there should be no 
traces of flux on the back of the board at all. Try to keep the 
remover off the front of the board, as you can't get under the 
sockets and other components well enough. 

Testing the Modified Little Board 

Check to make sure your Little Board still works properly by 
inserting a new set of 8 64k RAM chips (200ns is fine) in the 



sockets. Put the Little Board back in its case, connect everything 
up, and boot a disk. If all is well, everything will run normally. 
Try running some programs you are familiar with to be sure 
everything is OK. 

The MDISK Printed Circuit Board 

The MDISK board consists of seven basic functional sec- 
tions: 

1. Z80 

2. I/O port decoder and latch 

3. Refresh generator 

4. Memory chip selection 

5. A15 address generation 

6. A16/A1 7 address generation 

7. I to 4 banks of 256k RAM chips and associated buffers 
Let's look at each section, and then see how they are tied together 
to function as a single unit. 

TheZSO 

The Z80 is removed from its socket on the Little Board and 
plugged into a socket on the MDISK board. The MDISK board 
has a 40 pin board-to-board connector that plugs into the Z80 
socket on the Little Board. In this way, we can intercept the Z80 
signals that we need to modify in order to create extended RAM 
addressing, and then pass on the modified signals to the Little 
Board. 

The I/O Port Decoder and Latch 

The Z80 processor has 256 possible I/O ports. The AMPRO 
Little Board uses several of these for various functions, such as 
the floppy disk controller, serial ports, printer port, and on the 
later boards, the SCSI port. We chose to use port 30H as the 
MDISK control port as it is not used by the Little Board har- 
dware. 

In operation, the Z80 processor executes an OUT 30 instruc- 
tion and puts the contents of the A register on the data bus. Two 
comparators, UI and U2, monitor the address lines, and NOR 
gate U3c monitors the Z80 WR* and lORQ* lines, watching for 
the proper port address and generates a high pulse whenever an 
OUT 30 instruction is executed. This pulse will cause 8 bit latch 
U4 to latch and hold the A register contents from the data lines. 
This data will not change until the next OUT 30 instruction is 
executed or the reset button is pressed. 

These 8 data bits are used to generate the extra address bits 
needed for the 256K RAM chips and to control the MDISK drive 
select LED. DO is used as A15 when addressing the lower 32K of 
the Z80 address space. Dl and D2 are used to generate A16 and 
A17 for the RAM chips. D3 and D4 generate the RAM chip selec- 
tion for Bank 1, 2, 3 or 4. D7 is used to turn on and off the 
MDISK "drive select" LED, which is under software control and 
is used only to help the operator mopitor disk operations in 
progress. The D5 and D6 bits are not currently used. 



Editor's Note: 

The IEEE standard uses a new notation for logical and elec- 
trical stale relationships which is convenient with word 
processors. The overbar is no longer used to indicate an active low 
signal slate because it is difficult for many word processors and 
phototypesetters to set it. The suffix '"" is used instead to 
designate thai an electrical signal is active low, as in the Z 80 WR • 
above. 
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The Refresh Generator 

The Z80 was designed to work with dynamic RAM chips and 
is able to generate 7 bits of refresh internally and gate them onto 
the address bus at the proper times. This will support the full Z80 
address space of 64K, which is normally adequate. 256K dynamic 
RAM chips, however, require 8 bits of refresh to retain their con- 
tents. While the Z80 takes care of generating the refresh signals 
for A0-A6, the MDISK refresh generator circuit intercepts the 
Z80 A7 line and 8 bit counter UIO counts the refresh cycles, set- 
ting its output high for 128 cycles and then low for 128 cycles. 
During refresh cycles, U9 adds the output from UIO to the Z80 
A7 signal in order to provide the 8th bit refresh signal for the 
RAM chips. During non-refresh cycles, U9 passes the Z80 A7 
signal on unchanged to the address bus. 

RAM Chip Selection 

The chip select logic uses the CAS* signal required by the 
dynamic RAM chips. If a RAM chip receives a normal read cycle 
(except for the CAS* signal), it accepts it as a refresh cycle. If the 
CAS* signal is present, a memory read/write cycle is processed. 
The CAS* signal is generated by logic on the AMPRO Little 
Board and gated to the selected MDISK RAM chip. 

Address bit A15 is used to differentiate between the 32k 
global page of RAM in high memory and the various banks that 
MDISK swaps in and out of the lower 32k of Z80 address space. 
If A15 is low, bits D3 and D4 in latch U4 are gated to quad AND 
gate U5, selecting the bank to be swapped into the lower 32k. If 
A15 is high, addressing the upper 32k, the outputs of U5 are all 
forced low, making the high bank always Bank 1 Page 2 of 
memory. This provides a stable global base in the upper 32k of 
the Z80 64K address space for the operating system and RAM 
disk control. 

The outputs of U5 are fed into 2-4 decoder U7 as shown in 
Figure 1 . The outputs from U7 are fed to quad OR gate U8 along 
with the CAS* signal from the Little Board. Notice that there will 
always be a logical on one of the U8 OR gates. That gate will 
send the AMPRO CAS* signal to the selected bank of 256K RAM 
chips for the read/write operation. The other banks will process 
the cycle as a refresh. 
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A 15 Generation 

The Z80 A15 line is intercepted and regenerated by U3 and 
the DO output of latch U4 in order to control ail of the extra ex- 
tended RAM chip addressing. When it is high, the AI6/A17 and 
the bank select logic are all forced to a logical state, selecting the 
upper 32k of the Z80 address space, Bank 1 Page 2. All of the 
control software is executed from this area, simplifying the sof- 
tware and management of the memory banks. The system of 
memory banks is shown in figure 2. 

A16 and A17 Generation 

The AI6 and A17 address lines are generated from data bits 
stored in latch U4. Dl and D2 become the new address bits for the 
extra RAM chips, provided A15 is low. These two data bits are 



Figure 2 



Data Lines: 
8 Bit Latch: 



ZBU 

Address 

(Hex; 

FFFF IBank 1 I 

I Page i\ 

8000 IGiobail 



HDISK KAM Disk Memory Selection 

D7 Db D5 D4 D3 D2 Dl 

I i-ED 1 N/A 1 N/A I - 1 - I A17 i Alb 

i I I I I I I 



DO 
A15 



I 



I 



I 



Address Decoder / Multiplexer 



7FFF IBank. X|<— >|Bank 1 I 

I Page YK— >|Page 1| 

0000 I I I I 



IBank 1 I 
I Page 2 I 



IBank 1| 
I Page 3 1 



I Bank -• I 
I Page 8 I 



Bank X and Page Y are selected by the value In the 8 bit latch. 
Any bank can be selected, including the global Bank 1 Page 2. 

gated through the other two sections of AND gate U5 to 
multiplexer U6. 

Dynamic RAM chips use a multiplexed address line to 
decrease the number of pins required to address a large memory 
space. The first half is called the row address strobe (RAS), and 
the second half is called the column address strobe (CAS). During 
the RAS cycle, U6 will output the A16 bit and during the CAS 
cycle, it will output the A17 bit, thus providing the 256k RAM 
chips with the required A8 signal. This is coordinated with the 
other address lines by using the multiplexer select signal from the 




CALENDAR/CLOCK 

$69 KIT 



/ 

• Works with any Z-80 based computer. 

• Currently being used In Ampro, Kaypro 
2, Hi, 10, Morrow, Northstar, Osborne, 
Xerox, Zorba and many other computers. 

• Piggybacks in Z80 socket. 

• Uses National MM58167 clock chip, as 
featured In May '82 Byte. 

• Battery backup keeps time with CPU 
power off! 

• Optional software Is available for file 
date stamping, screen time displays, 
etc. 

• Specify computer type when ordering. 

• Packages available: 
Fully assembled and tested $99. 
Complete kit $69. 
Bare board and software $29. 
UPS ground shipping $ 3. 

MASTERCARD, VISA, PERSONAL CHECKS, 
MONEY ORDERS 6 C.O.D.'s ACCEPTED. 
N.Y. STATE RESIDENTS ADD 8% SALES TAX 

KENMORE 

COMPL'TER 

TECHNOLOGIES 

P.U. Box 63S. Kenmore. New Vork 14317 <7 181 MTTUMIT 
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Little Board, which we have jumpered to pin one of the Little 
Board RAM socket we are using for our RAM interconnect cable. 

RAM Banks 

The MDISK hardware will address up to four banks of 256k 
RAM chips located on the MDISK board. This will give us up to 1 
Meg of additional RAM. Some of the Little Board signals 
required for RAM operation, such as WR*, RAS*, and the 
multiplexed address lines A0-A7, are obtained from the Little 
Board RAM socket via the 6 inch 16 pin ribbon DIP interconnect 
cable that is plugged into MDISK socket J2, as they are not direc- 
tly available at the Z80 pins. The interconnect cable signals are 
buffered by U51 and U53 before being sent to the RAM chips. 

Operation 

We have now created a Z80 that has a "window" in the 
lower 32k of its 64k address space. This window can be filled with 
any 32k page of the extended RAM by loading the proper byte in- 
to the control port, as shown in figure 2. The upper 32k of 
memory is global and never changes, giving us the consistant 
work area we need for the operating system and the routines 
necessary to use the hardware as a RAM disk. 



Connecting It All Up 

Remove the Z80 from the Little Board and plug it into the 
Z80 socket on the MDISK board. Plug one end of the 6 inch 16 
pin ribbon DIP cable into the Little Board RAM socket that you 
have wired the jumper to, with the cable tail extending toward the 
rear edge of the Little Board (the edge with all the connectors or 
it). Carefully plug the MDISK 40 pin board-to-board connecto 
into the Little Board Z80 socket, plug the free end of the 16 pii 
ribbon DIP cable into J2 on the MDISK board. The MDISl- 
board requires 5 volts at 0.60 amps, which is supplied through J 1 
a standard 5 V* inch disk drive power connector. This is the sam 
type connector used by the Little Board. If your power suppl; 
doesn't have any extra plugs, a standard disk drive 'Y' powe 
connector can be used to supply both the Little Board and 
MDISK boards from one power supply plug. 

Next Time 

In part two we will present the software drivers that are ad- 
ded to the AMPRO BIOS in order to enable the Little Board to 
use the new extended memory as a solid state disk drive. These 
drivers must be added to the AMPRO BIOS source code, which is 
available directly from AMPRO, and is a worthwhile investment 
for anyone interested in learning about the inner workings of their 
operating system or in customizing or optimizing their system. ■ 
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Using the Hitachi HD64180 

Embedded Processor Designs 

By Kenneth A. Taschner & Frederick B. Maxwell 
Electronic Technical Services 



Jon Schneider gave us an introduction to the HD64180's 
features and programming in his two part series "The Hitachi 
HD64180: New Life for 8 Bit Systems," Computer Journal issues 
#27 & 28. We will try to build upon this by first covering the 
highlights of the part, followed some of the problems we must 
work around (virtually every complex piece of silicon or software 
has some bugs). In future articles, we will compare it to its com- 
petition, both 8 & 16 bit, for use in embedded processor design 
and we will cover the various versions of the 64180/Z180 and 
correct methods of interfacing to memory and peripherals. 

The popularity of the Intel 8080/85 series, the Zilog Z80 
series, and the newer National Semiconductor NSC-800 as em- 
bedded processors has established the viability and desirability of 
this basic, 8-bit architecture as a problem solving tool. While 
speed improvements have been made in both the Intel and Zilog 
processors since their introduction so many years ago, until the 
unveiling of the H£)64180 by Hitachi, this powerful architecture 
had not been updated with the introduction of a compatible, big- 
brother processor with additional features and/or powerful, on- 
board peripherals. The introduction of the Hitachi HD64180 has 
provided the stepping stone that designers have been looking for 
and that, up to now, has been unavailable. With this processor, 
Hitachi has given new life to many older systems. The HD64180 
allows engineers to upgrade existing designs without a major sof- 
tware re-write, to add additional features that require more 
memory addressing or speed than the older 8-bit processors were 
capable of, and, most importantly, allows the engineer to design 
in a processor that has an architecture and instruction set that is 
familiar to his software staff. 

The HD64180 is a desirable, supported part with many 
features that will cause it to be a major force in the embedded 
processor market. Being a CMOS chip, its power consumption is 
an enviably low 75mw at 6mhz clock speed. Its two ASCI (Asyn- 
chronous Serial Communications Interface) ports with built in 
baud rate generators provide the communications to the outside 
world that many embedded processor systems require. In addition 
the HD64180 has a third serial port which is intended as a high- 
speed inter-processor communications channel for multiple 
processor designs. Lastly, its extremely low cost will make it a 
serious contender where cost is an important consideration. 

A Family Affair 

The HD64180 is not an orphan. Its basic design will be made 
available as a standard ASIC (Application Specific Integrated 
Circuit) cell. An ASIC is a semi-custom part which consists of 
building blocks (cells) that can be put together by a hardware 
engineer to produce an IC customized to his design's requiremen- 
ts. This allows a company to reduce the parts count, assembly 
cost, debugging cost, repair cost, and physical size of its product 
by getting a large percentage of the parts needed in a single IC 
package. Unlike a hybrid circuit, an ASIC is a single piece of 



silicon. This allows an engineer to prototype a design using an 
HD64180 and to reduce the design to an ASIC package with few 
extraneous parts. 

The microcomputer market is not being ignored either, 
where Hitachi intends to package the HD64180 with RAM, 
ROM, EEPROM, I/O, and possibly A/D converters for sale as 
part of their growing family of single-chip microcomputers. This 
will allow an off-the-shelf part to be used in designs where an 
ASIC's initial cost cannot be justified and where individual com- 
ponents could consume too much board real estate (space) or 
could make the product too costly to produce. 

ALMOST 100% Object Code Compatible 

From an applications programmer's point of view, there isn't 
much to worry about when it comes to writing software, as most 
of the actual interfacing to the hardware has been done through 
the operating system or through BIOS calls. One problem that 
applications programmers must be aware of is a subtle difference 
between the Z80 and HD64180 when using the RLD or RRD nib- 
ble rotate instructions. The 280 flags reflect the contents of the 
accumulator upon completion of the instruction, as we would ex- 
pect, however, the HD64180's flags reflect the contents of the 
memory location pointed to by HL, an obvious error. The bug 
exists in all package styles in both the RO & Rl masks of the 
HD64180. The Zilog equivalent to the Hitachi HD64180, the 
Z180, is still in ALPHA test and, at the time that this is being 
written, it is not known if this bug has been fixed. Fortunately, 
this instruction is used to manipulate BCD type data and rarely 
are the flags checked after its use. If you must make a decision 
based on the results of one of these rotate instructions then OR 
the accumulator with itself to correct the flags. Please don't make 
the mistake of depending on this bug of the current 641 80 in your 
software, as it may be corrected in a future release of the part, 
and, it guarantees that your code will not run on the new Z280 or 
the older Z80 or NSC-800. 

Most of the problems that will need to be dealt with will oc- 
cur to the engineer designing hardware or to the systems level 
programmer writing the BIOS or, in the case of embedded 
processors, the low level device drivers. 

Wandering I/O Addresses 

The first issue we will cover will be the "64K" of I/O address 
space. One of the many enhancements of the 64180 over its 8 bit 
predecessors (8080,8085,Z80,NSC800 etc.) is the enlargement of 
its physical I/O address space from 256 I/O ports to 65536 I/O 
ports. This at first glance would appear to be heaven sent, 
especially since the onboard peripherals use 64 I/O ports, but 
great care must be used to actually reap any benefit from these 
new-found I/O ports. Where docs the 64180 actually get its upper 
8 bits of I/O address from? Herein lies the problem. The typical 
OUT (PORT),A can have disastrous effects in a 64180! Why, you 
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ask? Well, the designers of the 64180 use the contents of the ac- 
cumulator as the upper 8 bits (A8-A15) on the OUT (PORT), A 
instruction. To illustrate the problem let's look at typical I/O 
sequences and and their effect on the 64180's enviroment. 





Typical 


Z80 I/O 




DATA 
PORT 




E<3U 01 OH 
EQU 022H 




port. 


LD 
OUT 


A, DATA 
(PORT), A 


; Got data byte to output to 
; ...now send It. 



In the 64180, using this same code sequence the I/O port 
selected will depend on the contents of the register being output! 
Remember, A15-A8 is equal to the contents of the accummulator 
and A7-A0 is equal to the port specified so, DATA = lOH and 
PORT = 22H the effective port address is 1022H! Now let's just 
change DATA to 80H. Now the port address we output to is 
8022H! As you can see, this fairly common code sequence is 
useless on a 64180 using 64K I/O addressing. Is there a "work- 
around" for this design flaw? Fortunately, the answer is "yes." 
The register indirect OUT (C),A is actually equivalent to OUT 
(BC),A, so, just load the (BC) register with the actual physical 
address of the port to be output to. This can be done, because on 
a register indirect instruction A8-A15 reflects the contents of the 
B register! 



KCRD_ADOR 
DATA 



A Correct Method for 64180 54K 1/0 

Port address 



EQU 
EQU 



01022H 
OIOH 



LD 
LD 
OUT 



A, DATA 

BC,WORO_AOOR 

(C),A 



Byte to output. 

Set port address In <BC>. 

...now send it to port I022H 



learned long ago, no matter how little space this memory mapped 
I/O uses, someone will think they need the memory. Fortunately, 
it is unusual for a system to need so much I/O address space that 
256 ports are not enough, so designing for 256 ports and preser- 
ving the ability to use the Z80 and 64180 I/O instructions (yes you 
can use the new I/O instructions on any I/O port in the 256 I/O 
port address) is usually the way to go. 

64180 - ASCI Ports - Goodbye DART! 

The 64180 has 2 on-board, independent, full duplex ASCI 
ports with independant baud rate generators and control lines. 
Although both channels are very similar, there are some minor 
differences, primarily in the modem control lines. The ports share 
the following characteristics: 



o Full Duplex Communication 

o 7 or 8 bit data length 

o 1 or 2 stop bits (see text about bug) 

o 9th data bit for Multidrop ccniiiun I cat Ions (hardware 

must be configured for party line coawKjnIcat Ions) 
o Odd, even, no parity 
o Progrannable baud rate generator or optional external 

clock 
o Mode* control signals: 

Porto :0C00 -Data Carrier detect -(see text about bug) 
CTSO -Clear to Send 
RTSO -Request to Send 

Portl :CTS1 -Clear to send 
o PrograMMnable Interrupts (see text on precautions) 
o OMAC Operation - To be decussed In a future art! cat 
o Double buffered receiver and transaiitter 



As Jon Schneider suggests in his articles, it saves a lot of 
typing to generate include files to define absolute I/O addresses 
and then to refer to them using the same symbolic form as Hitachi 
demonstrates in their data book. We use a slightly different 
method than Mr. Schneider does. See the example below: 



This problem also exists on block I/O as seen in the following 
sequence: 



ASCI - Asynchronous Serial Co — unlcatlons 



Typical 


Z80 Block Output 


to Port 


CNTLAO 
CNTLAl 
etc. 


EQU 
EQU 


BASE+0 
BASEtl 


LO 
LD 
LO 
OTIR 


HL, BLOCK START 
B, NUMBER BYTES 
CPORT 


string to output to port. 
...string length to output. 
Port to output string. 
Output and repeat till done. 


Usage: 

BASE 
this 


EQU 
IMXUOE 



IBOPORTS.MAC 



ASCI Control REG A Chan 
ASCI Control REG A Chan 1 



Location of 64180 1/0 Ports for 
des i gn . 



Again the problem is that the OTIR instruction is using the B 
register as its repeat loop counter and the 64180 uses the B register 
as the upper address. Therefore, if B = 5 and PORT = 22H the 
bytes would be sent as follows. I/O addr. = 0522H, data = (HL) 
then I/O addr. = 0422H, data = (HL + 1), etc. 

A Correct MrHMd for 64180 Block i/0: 

Port address 

String to b« output to port. 
S«t port address in <BO. 

...string length to output. 
Get byte. 
Output byte. 
...next byte. 
...on* less to do> 
Keep going until string is 
ccaplete. 



There are hardware solutions to these problems, of course. 
One could set up an I/O port to act as an I/O page register for the 
upper address lines but the 64180 would not recognize this so we 
would lose 64 I/O addresses in each page to avoid conflict with 
the 64180's internal I/O ports. Another approach would be to 
memory map the I/O, but, as microcomputer manufacturers 



tMRO_AO0R 


EQU 01022H 


LD 


HL, BLOCK START 


LD 


aC.MRD'AbOft 


LD 


D.NUMBdf arrts 


LOOP: LD 


A,(HL) 


OUT 


(C),A 


INC 


HL 


DEC 


D 


JR 


NZ.LOOP 



We use this approach so that the same include file is used fo 
all of our designs regardless of where we locate the 64180's I/C 
ports. 

Before we start discussing the serial port registers and simpl 
programming of the ASCI channels under programmed I/O anc 
interrupt let's cover the two problems on which we receive the 
most phone calls. 

Stop Bits 

Most cotmnonly used UARTS on the market will allow the 
user to specify whether to use 1 or 2 stop bits. What stop bits 
specify, in reality, is the delay between characters. UARTS that 
support this feature, if programmed for 1 stop bit. wiU wait 1 bit 
time at the end of the character being transmitted before starting 
the next character transmission. If 2 stop bits are requested they 
will insert 2 bit times before sending the next character. Regar- 
dless of the number of stop bits specified, the visi majority of 
UARTS only require 1 stop bit on a received charaaer. There is a 
not so obvious advantage to this: Most systems will use only 1 
stop bit above 300 baud. This decreases the communicauons time 
by approximatly 10^. In many cases this savings isn't actually 



The Computer Journal / Issue #29 



19 



realized due to proccessing overhead on one or both sides of the 
link. Some computers are fast enough to keep the UART full so 
there is no break in the transmission stream, but, many "in- 
telligent" peripherals are not quick enough to get the character, 
process it, determine whether to try to stop the transmitter by 
toggling a handshake line, etc. These devices (most notably 
CRT's and PRINTERS) gain the extra time they need when the 
transmitter inserts an extra stop bit. Therefore, a common prac- 
tice, with fast I/O processors, is to send 2 stop bits and receive 1, 
being compatable with virtually all peripherals. 

The 64180 ASCI channel, although technically correct, 
requires 2 stop bits on receive if the transmitter is programmed for 
2. If the ASCI port on the 64180 is programmed for 1 stop bit it 
will work with most devices whether they are programmed for 1 
or 2 stop bits (preferred usage). The exceptions to this, being the 
aforementioned intelligent terminals and printers which fail to 
operate at higher baud rates (9600 and above) without delays. If 
the 64180 is programmed for 2 stop bits the device it com- 
municates with MUST always send 2 stop bits or the 64180 will 
misinterpret some characters. Hitachi has indicated that future 
versions of the 64180 (available Spring of 1988) will conform to 
the same conventions used by other industry-standard UARTs so, 
until then, it is recommended to only use 1 stop bit. 

Data Carrier Detect - Stop Interrupting Me! 

DCDO* (Data Carrier Detect Channel NOT) is a status line 
into ASCI channel 0. If this line is in the normal (logic 0) state, 
channel O's receiver behaves normally. If the DCDO* changes to a 
disconnected (logic 1) state, ASCI channel O's receiver is disabled. 
It will not be re-enabled until DCDO* returns to a logic AND 
STATO is read. The first time STATO is read, it will indicate that 
the device is disconnected and will cause the ASCI to re-evaluate 
the DCDO* line condition. If DCDO* indicates that there is a 
device present, the receiver is immediately activated. When 
STATO is re-read, the actual status of the DCDO* line will be in- 
dicated, so remember, if DCDO* indicates that there is no device 



connected, re-read STATO if you need to know the actual status 
of DCDO*. 

The reason that this operates in this manner is to prevent the 
processor from interpreting line noise as legitimate data when no 
device is connected and this works fine as long as the serial data is 
gathered as programmed I/O. Where a potential problem can 
arise is using interrupts with ASCI channel 0. Whenever DCDO* is 
high, an interrupt will be generated. This is the same interrupt 
generated by the channel receiver, so, before a character can be 
read, it is the programmer's responsibility to read STATO and 
assure that the interrupt was not generated by a change in the 
DCDO* line. If it was caused by the DCDO* line and interrupts are 
re-enabled before the DCIX)* line returns to a logic 0, we will be 
hit by another interrupt immediately. This will also happen if the 
interrupts are re-enabled before we read STATO and determine 
that the DCDO* problem has been corrected. This is because this 
is a level sensitive interrupt. It will interrupt whenever the level is a 
logic 1, not just once, as an edge sensitive interrupt would. Ob- 
viously, the stack will get blown away if we enable and get in- 
terrupts before returning from the one we're servicing! In a 
correctly designed RS-232C interface, line noise is not a serious 
problem, so the obvious solution to this problem is to simply 
ground DCDO*, preventing this disastrous problem from ever oc- 
curring. A much more intelligent design would have been to 
generate an interrupt on a change of state of DCDO* rather than 
on a level. 

Future Installments 

In upcoming articles, we'll discuss programming the serial 
ports, memory interfacing to the HD64180, clock speed vs. baud 
rate, and more! ■ 

Editor's Note: We want to expand this HD64180 section, so send 
any tips, ideas, questions, or answers. We would also be in- 
terested in hearing about what you are doing with the '180, 
especially any unusual applications. 



North American One-Eighty Group and Electronic 
Technical Services 

Hardware and Software support for Z80/HD64180/Z280 Computers 



•The Dat«Stamp«r Time and date stamping facility for Z- 
System and CP/M 2.2 files, provides creation, access and 
modification time and date, also supports a hardware-in- 
dependent Real Time Clock interface. Includes many support 
utilities, even works with SB180's "heartbeat" clock. 
From Plu* Perfect Systems, $49.96 complete plus $3 s&h 
•Hl-T«ch C Plus: Professional C compiler produces ROMabie, 
reentrant code, runs under Z-System or CP/M, interchangeable 
Z80- and HD64180-optimlzed libraries with source, single- 
precision floating point support, assembler/linker, conversion 
utility for use with M80 and SLR assemblers. Function 
prototyping and 31 -character names supported. 
From ETS: $195 complete plus $3 s&h 

•The One-Eighty File: "The chronicle of the 8-blt renaissan- 
ce" — the monthly newsletter of North American One-Eighty 
Group (NAOG) and ZCPR Systems Interest Group (ZSIG) keeps 
you up-to-date on the latest PD and commercial software 
releases, advanced 8-bit hardware developments, inexpensive 
PD disks, hardware savings, tips for programmers and users. 
From NAOG/ZSIG: $15 for 12 issues ($25 outside North 
America) 



• ETS-180-IO + : Add-on board for SB180 provides two 1 15.2 kbps 
serial ports, SCSI interface, battery-backed Real Time Clock, 24 
bits of parallel I/O, XBiOS, DateStamper, full Z-System support 
Included. 

By ETS, $299.95 complete plus $15 s&h (Includes NAOG mem- 
bership) 

•XBIOS: Flexible operating system for SB180 and SB180FX has 
cached disk I/O, expanded TPA, menu-driven installation. In- 
cludes DateStamper, utilities, supports Z-System and both 
MIcroMInt and ETS add-on boards. 
By Xsystems Software, $74.95 complete plus $3 s&h 

• Backgrounder It (BQII): Full task swapping for Z-System and 
CP/M 2.2 computers, suspend current task without losing your 
place, supports two Independent TPAs plus many always- 
available Internal commands, Includes Print Spooler, screen 
and function key drivers, much more. 

From Plu* Perfect Systems, $74.95 complete plus $3 s&h 

Call 215-443-9031 during East Coast business hours 
MasterCard & VISA accepted 
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Big news 

for the brave 

few of you 

who started this 

whole thing. 



WDRD 
SIAR* 

CP/M' Edition, 
Release 4. 

Finally, all the "if only 's." Over 100 truly useful improvements including undo, macros, on-screen boldface and underline, and 
multiple ruler lines stored with documents. Even something to help you get the most from your laser printer Everything you 
need to be at the forefront of technology. Again. 

System requirements: CP/M-802. 1 or higher; 54K TPA w/Math (51 K TPA without Math). Disk requirements: two 5-1 /4 " DD 
drives, or two 8" drives, or one DD floppy drive and a hard disk. 

To order WordStar, CP/M Edition, Release 4, fill in this coupon and send your check or money order to: MicroPro Order Update Department, P Box 70T9 
San Rafael, CA 94901-7079. Or caU toU-free 800-227-5609 Ext. 762. Allow M weeks for delivery. 

Name Osborne' format 5-1 /4 " disks CP/M Release 4 $89.00 

^^(jjjfgjj Kaypro" format 5-1/4 "disks Tax* 

City State Zip Generic 8 "disks , , ki r>.-. k, ■a7> Shipping/ Handling S5.00 

■' ^' Apple* format 5-1/4 "disks (available October 87) 

Company Name WordStar Serial No or include title page ^°^ 

Telephone ( ) of your WordStar Reference Manual. 'Onfy these siaiesrvqum sales lax: 

CA. GA. IL .VM. SJ. .\y: OH. TXand VA. 

WordStar and MicroPro are registered trademarks of MicroPro International Corporation. CP/M is a registered trademark of Digital Research. Inc. 

A II other product names and trademark information are listed for purposes of description only. i a«7 M ktid Pro 



The ZCPR3 Comer 

Announcing ZCPR33 & Z-COM Customization 

by Jay Sage, Echelon, Inc. 



One of the problems with writing a column for a magazine 
that only appears every two months or so is that so many things 
can happen between when one column is written and the next one 
is published. (Of course, there would be other, insurmountable 
problems if I had to turn out these columns every month, so I am 
not complaining.) At the end of the last article, I mentioned that 
ZCPR33 would probably be out by the time that issue appeared. 
Indeed, that was true. What I did not write, because no public 
announcement had been made yet, was that I had joined the 
Echelon team and would be the author of that version. So I am 
now wearing two hats, one as ZSIG software librarian and one as 
the Echelon team member in charge of command processor 
development. Richard Conn has gone off to do more esoteric 
things. In recognition of this change, I have broadened the title of 
this column. 

ZCPR Version 3.3 

Since ZCPR33, or Z33 as I will call it for short, is too exciting 
a subject to pass up, I will say a few words about it before con- 
tinuing the discussion we began last time of techniques for 
customizing Z-COM. 1 will not say too much, however, since a lot 
of effort already went into preparing the 60-page "ZCPR33 User 
Guide." It has all the details and is available from either Echelon 
or Sage Microsystems East for $15 plus shipping ($3 from SME). 
Since the code, as in the past, is still available free of charge for 
personal, noncommercial use, sale of the manual is the only way 
other than OEM sales that we get any compensation for the 
enormous amount of effort that went into Z33. I will talk this 
time only about the design goals for Z33, and perhaps in future 
columns I will talk about some of the new features and 
capabilities. 

Design Goals 

In developing Z33, 1 tried to achieve five things (the number 
keeps growing every time it think about it). (1) I have tried to 
maintain a very high level of compatibility; (2) I have tried to in- 
crease flexibility, control, and speed; (3) I have tried to make the 
code rigorous and reliable; (4) I have tried to make more infor- 
mation about the internal state of the command processor ac- 
cessible to user programs; and (5) I have tried to make the code 
readable and educational. 

To the greatest extent reasonable, 1 have maintained com- 
patibility between Z30 and Z33. No change need be made to any 
part of the operating system other than the command processor; 
the Z33 command processor, as I hinted at in the last column, can 
simply be dropped in wherever the old command processor was, 
either on the system tracks of the boot disk or in the appropriate 
places in a Z-COM system. No changes need be made in the 
memory allocations, and the officially released system modules 
that worked with Z30 will work with Z33 as well, though new, 
more powerful RCP and FCP modules were released with Z33 



(the 'H' command in the unofficial experimental RCP145, 
because it made direct references to internal addresses in the 
CPR, will not work). All application programs and almost all 
utility programs will work unchanged with Z33. New utility 
programs have been written to take advantage of some of the new 
features in Z33. 

Many features of ZCPR3 — such as automatic path sear- 
ching for COM files, extended command processing, and error 
handling — are very convenient but can significantly slow system 
response. With Z33, the user is given greater control over these 
features from the command hne so that unnecessary operations 
can be bypassed to save disk activity and time. No longer does the 
path automatically include the current directory first. The user 
can now, at his option, omit the current directory or include it in 
any position in the path. This has a dramatic effect on system 
speed. A command entered with a leading slash ('/') is handled 
directly by the extended command processor without wasting time 
searching the path for a COM file. For systems that take in- 
creasing advantage of ARUNZ or other extended command 
processing, speed is, again, greatly improved. Programs with 
what is called a type-3 environment are automatically loaded and 
executed at addresses other than 1(X)H. By loading error handlers, 
shells, and extended command processors high in memory, user 
programs at lOOH are left intact and can be reinvoked using the 
GO command. 

The code in Z33 was almost totally rewritten, taking only the 
basic functions from Z30. Quite a few bugs, some very serious, 
were corrected, and new algorithms were used for many of the 
functions. A great deal of effort was devoted to making the code 
rigorous. No longer can a command tail longer than 128 bytes 
overwrite the program code and crash the system. No longer can 
command lines in SUBMIT files write beyond the end of the 
command line buffer. The root path and minimum path features 
now work correctly, so that duplicated elements in the search path 
do not have to be searched more than once. Extended command 
processing functions reliably and in combination with error han- 
dling. 

The Z33 command processor makes much more information 
available about its operation. In Z30, only COM files that could 
not be found would invoke error handling. Z33 traps many dif- 
ferent kinds of errors, and it can report the nature of the error to 
the user. Some examples are TPA overflow, disk full, bad 
numerical expression, incorrect password, bad directory 
specification, or ambiguous file specification. Z33 even makes it 
possible for user programs and routines in the resident command 
package to invoke error handling and to report the type of error. 
When Z30 parsed a file expression that specified an invalid direc- 
tory, it simply substituted the current directory, but the program 
had no way to tell that this had been done. Z33 sets a flag to in- 
dicate the error. With Z33, a program can tell where on the search 
path it was actually found. This can be valuable for shells and 
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error handlers that install themselves into the system. They can 
operate faster if they know where they are located. 

Finally, the source code has been completely reorganized and 
very extensively commented. I did this not only to make it easier 
for me to maintain it but also so that others could read it to learn 
how the command processor works. One of the main reasons why 
many of us hobbyists remain involved in the 8-bit world is that a 
Z80 can be comprehended fairly easily and can thus be used to 
learn deeply about the operation of a computer. Z33 is designed 
to contribute to this. 

Advanced Z-COM Customization 

In our discussion last time we described what Z-COM is and 
how it works, and we presented a number of techniques for 
carrying out simple modifications that did not alter the basic 
structure of the Z-COM system. This time we will examine some 
much more far-reaching modifications, including those that in- 
volve changing the way Z-COM operates. The goal is to develop 
techniques that will permit us to use the basic principles behind Z- 
COM to build arbitrary systems of our choice. I do want to warn 
you: a good part of this discussion will be at an advanced 
technical level. Even I feel rather mentally exhausted after going 
through the process of developing it and writing it down. If any 
one section is getting too technical for you, please do not give up 
completely. Skip ahead to each new section and read the in- 
troductory philosophical comments. There is material there that I 
would really like everyone to see. 

When Z-COM Will Not Work 

Before launching into the heavy code patching, I would like 
to cover a topic that probably should have been included last 
time: why Z-COM will not work in all systems or will not work 
fully. 

There are two circumstances that I have experienced in which 
Z-COM interferes with the proper operation of a system. One 
class of difficulties arises when the system uses utilities that make 
modifications to the operating system image in memory. Such 
utilities always invite disaster, but they are nevertheless quite 
common (partly because they are so useful). If the utilities 
calculate the addresses to change from the BIOS wannboot ad- 
dress at location 0001 , then there will be trouble, because that ad- 
dress points to the virtual BIOS set up by Z-COM and not to the 
real BIOS. 

The Ampro BIOS, for example, has a number of special 
structures in defined locations with respect to the beginning of the 
BIOS. Some of these, for example, support the various con- 
figuration options. Since these options are rarely changed except 
when the system is first assembled or when new hardware is ad- 
ded, one can overcome any problem by running the utilities when 
Z-COM is not in operation. Other BIOS structures are used to 
defme the alternative disk formats. These one might want to 
change during a session at the computer. Although it is incon- 
venient, one could again exit from Z-COM using ZCX, change 
the disk format, and then reenter Z-COM. Of course, a conven- 
tionally installed ZCPR system is available for the Ampro so that 
Z-COM is not necessary. However, a number of other computers 
running standard CP/M 2.2 use similar techniques and have 
similar utilities. 

The second class of difficulties arises when the BIOS war- 
mboot code performs some indispensable function. Remember 
that when Z-COM is running, the warm boot is intercepted, and 
the warmboot code in the original BIOS does not run. My 
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BigBoard I with the double-density upgrade automatically selects 
from a large number of disk formats. One simply puts the diskette 
with the new format into the drive and presses control-c. The 
warmboot code in the BIOS includes code for determining the 
format of the diskette. When Z-COM is running, I often ex- 
perience problems when I try to log in a new drive for the first 
time or when I try changing disk formats. The trouble seems to 
have to do with the way the BIOS keeps track of what drives are 
logged in, and by using disk resets or control-c's from Z-COM, ! 
can often get the system to work. But clearly there can be 
problems when the BIOS warmboot code is completely by-passed. 

More Named Directories 

To get our feet wet again with Z-COM patching, let's stan 
with a relatively simple but very practical example. The most 
frequent request I get from users of Z-COM, especially those 
using it to make a remote access system, is for a way to increase 
the number of named directories. 

To refresh our memories, I have reproduced in Figure 1 the 
memory map of our unmodified Z-COM system. Those of you 
who are really sharp (or have photographic memories or are 
cheating by actually looking at the last issue) will notice that this is 
not exactly the same as the map presented last time as Figure 2. 
The reason for this is that I recently was offered a deal that I sim- 
ply could not refuse on a hard-disk Televideo 803H system (every 
household needs four complete computer systems, no?). Since I 
caimot bear to operate a computer without Z-System, I im- 
mediately implemented Z-COM on it and have been using it as the 
testbed for the techniques described here. It's BIOS is obviously 
even less compact than the one on my BigBoard and staru 200H 
lower in memory. I hope this address switch does not confuse you 
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too much, but since your system probably does not match mine 
anyway, you have to get used to translating addresses. The ad- 
dresses in the ZC.COM image, of course, do not change. 
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Now, if we want to have room for more directory names, we 
have to find a way to allocate more memory to the NDR module. 
Where can we steal some memory? Unfortunately, the memory 
cannot be taken from either of the neighbors of the NDR. The 
virtual BIOS and shell stack are indispensable. That means that 
we will have to move the NDR or something else from its present 
position. The best target for our memory raid is that hulking 6- 
page, 1.5K lOP that often goes unused, especially on remote ac- 
cess systems. We will cut it down to 3 pages and use the top 3 
pages for our new NDR, which will have a capacity for 42 names [ 
(3 • 256 - 1 ) div 18 = 42 ]. The resulting memory map is shown in 
Figure 2. 
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To implement this change in our Z-COM file we have to 
change only the ENV and CPR modules. The ENV has to know 
about the new memory map, and the CPR code has to know 
where the NDR module is located. Although the NDR module 
will be placed in a new location in the ZC.COM file, the NDR 
data are position-independent, so the module itself need not be 
changed (though we will presumably be adding many new names). 
The FCP and RCP are still in the same place doing the same 
thing. 

One of the new features of Z33, by the way, is the ability to 
determine the locations of the NDR, FCP, and RCP from the en- 
vironment descriptor. Thus if we are using ZCPR33 with this 
feature enabled, no change in the CPR code is required. 

Only three changes in the Z3BASE.LIB file are required to 
reflect the new memory map. These are the definitions for the 
symbok lOPS (the number of 128-byte records allocated to the 
lOP), Z3NDIR (the address of the NDR), and Z3ND1RS (the 
number of names in the NDR). These changes are as follows: 
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The new SYS. ENV file can be made either by assembhng 
SYSENV.ASM with the modified Z3BASE.LIB, or it can be 
done by patching (either to the image imbedded in ZC.COM or to 
the standalone ENV file). I didn't have a copy of SYSENV han- 
dy, so I have been using ZPATCH (which is much more fun 
anyway). I find that I am constantly in need of the addresses of 
various items in the environment descriptor, so to make them 
easier to find, I took my copies of Richard Conn's "ZCPR3, The 
Manual" and put a 3M Post-It® (one of those wonderful httle 
yellow semi-stick note sheets) on page 300 where the SYSENV 
module is described. Then I wrote the offsets shown in Figure 3 
into the margin next to the symbols. It was thus very easy to 
determine that the addresses to patch in the ZC.COM image are 
ICl IH (lOPS), 1C15H (Z3NDIR), and 1C17H (Z3NDIRS). 
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The next steps were to assemble up a new version of the 
command processor, create the desired NDR file, and then put all 
the pieces into the ZC.COM file as described last time. While I 
was at it, I decided that it would be nice if this new version could 
co-exist on the system with the previous version, in case I ever 
wanted the full lOP space back temporarily. To achieve this, 1 
made two additional changes in the image and saved it to a file 
called ZCl .COM instead of ZC.COM. These two changes were to 
the name of the startup alias and the name of the CPR file to be 
loaded from A15 by the warmboot code. 

The startup command is stored in the multiple command line 
buffer, whose image begins at IDOOH. The standard ZC.COM 
has the following data there for my Televideo 803H with its real 
MCLatDSOOH: 

<04> <D5> <CC> <04> s T R T <00> 

The first two bytes are a pointer to the address D504, where the 
next command (in this case the only command) to be executed is 
stored. They do not have to be changed. The third byte, CCH, is 
the maximum number of characters that the command line can 
contain. It should not have to be changed, but in fact the value is 
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wrong. Fortunately, this mistake can only cause trouble in highly 
exceptional circumstances, but while we are at it we can put in the 
correct value of CBH = 203. The value of the symbol Z3CLS in 
Z3BASE.LIB should also be changed. The correct value is the 
maximum number of actual characters in the command line. As 
can be seen above, there are four bytes before the command string 
and one byte (the terminating null) after it. Hence the proper 
value for Z3CLS is five less than the total amount of memory 
allocated to the multiple command line buffer module. 

The fourth byte is the number of text characters in the com- 
mand hne. This value is never used by the operating system, but 
the DOS line input function writes the count to that position, so 
we have to provide space for it. If you put a wrong value there, it 
will not make any difference, at least not for the operations per- 
formed here. I have heard that there was at least one utility 
program that used this value for some purpose. I do not recom- 
mend this practice, since some command-line-generator 
programs, I believe, do not update the value after they produce 
their command lines. I am also not sure whether or not the Z3LIB 
routines APPCL and PUTCL update the character count. 

To make ZC1.COM use a startup alias called STARTl (6 
characters), we would change theMCL buffer to 

<04> <05> <C8> <06> STARTl <00> 

This can be done either with ZPATCH or a debugger. If there is a 
lot of garbage in the rest of the command line buffer, you can fill 
it with zeros out through address IDCFh to make things look 
neater. 

The file control block for the ZC.CP command processor 
image that is loaded from directory A15 starts at address 1944H. 
By changing the space character at address 1947H from 20H to 
31H ('!' ASCII), the CPR image ZCl.CP will be loaded instead. 
You can also change the message at address 1901H to reflect the 
name of the CPR image file. There is room to squeeze two extra 
characters into that message, one by eliminating the leading space 
and one by omitting the ending period. After you're done with 
these changes, don't forget to put the CPR image file ZCl.CP in 
A15. 

It seems wasteful with this configuration to leave unused the 
block of memory where the NDR used to be. When I implemen- 
ted this version, I moved the multiple command line buffer there 
so that I could increase its size from 208 to a full 256. One might 
not enter such long commands by hand, but aliases and other 
command line generators occasionally overflow the 203 character 
limit in the usual configuration. For ZCPR34 I am considering 
some techniques for extending the length to a two-byte value so 
that the command line can be as large as one would like. I will not 
describe the extra changes required to move the command line 
buffer, since the next example will cover that and more. 

Completely Revamping the Memory Model 

We will now consider how we go about completely revam- 
ping the memory model, including moving the lOP. Moving any 
module except for the lOP can be accomplished using a straight- 
forward extension of what we have already described. The lOP 
poses some special problems that we will now deal with. 

Before turning to that subject, I would like to make some 
general comments about the memory allocation in a ZCPR3 
system. With a fixed system — that is, any particular system that 
one will use at all times — it does not really matter how the 
modules are distributed in memory, just so long as they all fit 
somewhere. 



As soon as one wants to be able to change from one system 
configuration to another, not all memory models are as good as 
others. I first noticed this when I wanted to run both Z3-DOT- 
COM and Z-COM on my system. I usually used Z3-DOT-COM 
because it left a larger TPA, but occasionally I wanted to make 
use of the lOP for redirecting console output to a disk file. At 
that point I discovered that Joe Wright's choice of memory 
models was a poor one. By adding the lOP at the top in Z-COM 
rather than at the bottom, the environment descriptor moved 
down to a lower address, and that meant that I either had to have 
two sets of utility programs or had to reinstall all the utilities every 
time I changed from one system to the other. This provided a 
powerful incentive to discover methods for modifying the 
memory maps. Of course, with ZCPR33 and its automatic in- 
stallation of utilities, this is no longer a concern. 

Even with ZCPR33 there are compelling reasons to choose 
some memory configurations over others. The addresses of most 
system components are hard-coded into even the ZCPR33 com- 
mand processor. However, as we mentioned earlier, the addresses 
of the largest memory buffers — the NDR, FCP, and RCP — can 
determined dynamically from the environment descriptor in 
memory. As a result, if these buffers are placed adjacent to one 
another, the single block of memory allocated to the set of them 
can be reconfigured simply by loading a new environment 
descriptor. Since the command processor does not directly refer 
to the lOP, the lOP can also be included at the bottom of this 
single buffer space. The tradeoffs that become possible are 
illustrated in Figure 4, where a single memory block of 4.25K (the 
standard amount in Z-COM for these modules) is allocated in two 
different ways. 
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In the alternative memory map in Figure 4 the lOP buffer 
has been shrunk to a single record, a space just large enough to 
hold the dummy lOP that Z-COM comes with (we can't shrink it 
to zero without changing the VBIOS). The extra 1 1 records of 
memory are then distributed to the other modules. The NDR in- 
creases to 6 records, enough for 42 named directories. The FCP 
picks up 3 more records. At 7 records, it has enough space to im- 
plement a very large number of resident test options. The 
remaining 4 records go to the RCP, which can probably now in- 
clude all options in Z33RCP. 

Suppose the standard configuration is described by 
SYS.ENV and uses the modules SYS. NDR, SYS. FCP, and 
SYS. RCP, and that the alternative configuration is described by 
ALT.ENV with modules ALT.NDR, ALT.FCP, and ALT.RCP. 
Then we would change from the standard to the alternate con- 
figuration by entering the command 

LOR ALT.ENV, ALT. NOR, ALT. FCP, ^LT. RCP 

Note that it is essential that the ENV module be listed, and 
therefore loaded, first. If it is not, LDR will not know the correct 
addresses for the other modules. Similarly, to change back to the 
standard configuration, one would use the command 

LOR SYS. ENV, SYS. NOR, SYS. FCP, STS. RCP 

If one were switching back, for example, to use the NuKey lOP to 
provide keyboard macro capability, the line could read 

LOR SYS.ENV,SYS.NOR,SrS.FCP,STS.RCP.NUKET.I0P 

In this way one can make much more flexible use of system 
resources. One might choose to reduce the size of the overall buf- 
fer space to only 35 records, keeping only the lOP stub in the 
standard configuration. Then when an lOP like lOR (I/O recor- 
der) or BPRINT (print spooler) is needed, the RCP and/or FCP 
would be contracted temporarily. Either one or both could even 
be eliminated (reduced to zero size). Aliases can be used to 
automate the process of switching configurations. 

Moving the lOP 

We will now build a Z-COM system of the form described 
above. The memory map for the new configuration is shown in 
Figure 5. Since the ENV (including TCAP) is a fixture in any 
system, I would have preferred to put it in the invariant position 



at the very top of memory. However, ZRDOS has to know where 
the ENV is in order to support wheel-locking of files. If you have 
purchased ZRDOS separately, you can generate a version to run 
at any address and to reference an ENV at any address. If you 
only have Z-COM, however, you do not have this freedom. 
Therefore, I have left the environment where it was. 



Systeai (kMponent 

operating systeai modules 

CPR 

ZROOS 

Virtual BIOS 
large, variable buffers 

1/0 Package 

Resident Coeaiend Package 

Flow Control Package 

Naaied Directory Register 
third page of buffers 

Shell Stack 

Z3 Message Buffer 

External FC8 

PATH 

Mheel Byte 
second page of buffers 

Environaient Descriptor 

TCAP 
top page of buffers 

Multiple Coenand Line 

External Stack 



ZC.COM Address 



0200 - 09fF 

OAOO - 1 7FF 

1800 - 19FF 

lAOO - 1FFF 

2000 - 25FF 

2800 - 27FF 

2A0O - lAfF 

2B00 - IB7F 

2B80 - IBCF 

2800 - 1BF3 

2BF4 - IBFE 

2BFF - IBFF 



2C00 
2C80 ■ 



2000 
2D00 ■ 



1C7F 
2DfF 



1DCF 
1DFF 



System Address 



BAOO - CIFF 
C200 - EFFF 
DOOO - OlFF 

0200 - 07FF 
0800 - DfFF 
EOOO - EIFF 
E200 - E2FF 

E300 - E47F 
E3e0 - E4Cf 
E300 - E4F3 
E3f4 - E4fE 
E3FF - E3FF 

E400 - E47F 
£480 - E4FF 

E500 - E5CF 
E500 - E5FF 



F 1 gure 5 . 
under 2CPR33. 



y Map for a systea designed for dynamic buffer reallocation 



The first step, as usual, in making a new configuration is to 
prepare a new Z3BASE.LIB file. The important addresses in that 
file are shown in Figure 6. I have considered each page of memory 
to be a unit. The bottom of the page is referenced to the real BIOS 
address, and the other modules in the page are referenced to the 
base module for that page. Of course, you can express these ad- 
dresses in many other equivalent ways, and you may well prefer to 
do it differently. In any case, with Z3BASE.LIB in hand, you can 
assemble up the CPR, RCP, FCP, and ENV modules (or you can 
make the latter by patching). 





; 236ASE.LIB 








rbios oqu 


OeeOOh 






; First page under BIOS 






z3cl equ 


rblos - lOOti 






z3cls equ 


205 






extstk equ 


z3cl + OdOh 






; Second page under B 


OS 






23env equ 


rbios - 200h 






i3«nvs equ 


2 






; Third page under BIOS 






shsTk equ 


rbios - 300h 






shstks equ 


4 






shsize equ 


32 






z3asg equ 


shstK * oaOh 






•xtfcb equ 


shstk * OdOh 






expath equ 


shstk * 0f4h 






axpaths equ 


5 






z3i«h t equ 


shstk ♦ Offh 






; Variable Modules 








z3nd(rs equ 


14 






z3ndlr equ 


rblos - 0400h 






tcps equ 


4 






fcp equ 


23ndfr - fcps*eoh 






reps equ 


16 






rep equ 


fcp - rcp$*80h 






lops a<)u 


12 






lop equ 


rep - (ops»80h 






; Operating sysraa coapoowits 






vblos equ 


(op - 0200h 






dos equ 


vblos - 0«00h 






ccp equ 


dos - oeooh 




Figure 6. A<)Or«ss equattts for 


rtim Z36AS£.LrB file corresponding 


to 




iry configuration shown 


In Figure 5. 





We would be able to implement this configuration without any 
problem using the techniques we have already seen were it not for 
the lOP module. The lOP is really an extension of the BIOS, and 
the problem is that the virtual BIOS has vectors (jump instruc- 
tions) going to the lOP. When the Z-COM system is built by the 
loader program ZCLD.COM, the addresses are calculated based 
on the assumed relative positions of the VBIOS and lOP. Since 
we are now going to change the spacing between them, we will 
have to perform some patching on the VBIOS module. 
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The table of jump vectors in the virtual BIOS is shown in 
Figure 7. There are two jumps (warm and cold boot) that are in- 
ternal to the VBIOS, 7 jumps to addresses in the lOP (6 in one 
group and one extra), and 10 jumps to the real BIOS. Only the 
jumps to the lOP have to be changed. 



(00) 


VBIOS: 


JP 


VBIOS » 67H 


; coldboot 


(031 




JP 


VBIOS * 67H 


: ■ar«6oot 


(06) 




JP 


lOP ♦ OCH 


; console status 


(09) 




JH 


lOP » OFH 


; console Input 


(OC) 




JH 


lOP ♦ 12H 


; console out 


(Of) 




JP 


lOP t 15H 


: 1 1st out 


(12) 




JP 


lOP t I8H 


; punch out 


(15) 




JP 


lOP » IBH 


; reader In 


(18) 




JP 


BIOS <■ IBM 


; hoMa disk 


(IB) 




JP 


BIOS t IBH 


; select disk 


(IE) 




JP 


BIOS ♦ lEH 


; set track 


(211 




JP 


BIOS * 21M 


: set sector 


(24) 




JP. 


BIOS » 24H 


; set OMA 


(27) 




JP 


BIOS t 27H 


: read sector 


(2A) 




JP 


BIOS t 2AH 


; wr 1 te sector 


(2D1 




JP 


lOP t lEH 


; 1 1st status 


(301 




JP 


BIOS •■ 50H 


; sector translation 


Figure 7. Structure of 


the 


junp table in the 


virtual BIOS. 



You should begin by making a copy of ZCl .COM, which we 
generated earlier, giving it the name ZC2.COM. Then determine 
the absolute address of the lOP in your system. Next, go into 
ZC2.COM with ZPATCH or with a debugger and change the ad- 
dresses. For my Televideo 803 H system the lOP had been at 
EOOOH and is now at D200H. I would look for the seven jumps of 
the form "C3 ?? EO" and change them to "C3 ?? D2". 

We also have to make some changes to the code in the dum- 
my lOP. It has a total of 16 jump instructions, 7 of which refer to 
the real BIOS and 9 of which refer to internal addresses. The for- 
mer need not be changed, but, since we are changing the address 
at which the lOP will execute, we have to change the latter ad- 
dresses. The source code for the dummy lOP is shown in Figure 8. 



(00) 
(03) 
(061 
(09) 
(OC) 
(OF) 
(121 
(15) 
(IB) 
(15) 
(IB) 
(IB) 
(IE) 
121) 
(24) 
(27) 
(30) 
(30) 
(3£) 





lOP t 30H 


; status 




lOP + 30H 


; device select 




lOP ♦ 30H 


: device ntmm 




ICP ♦ 30H 


: Initialization 




BIOS t 0«H 


; console status 




BIOS t 09H 


; console input 




BIOS t OCH 


; console output 




BIOS ♦ OFH 


; 1 1st output 




BIOS ♦ I2H 


: punch output 




BIOS ♦ 15H 


; reader Input 




BIOS * 20H 


; 1 1st status 




lOP t 30G 


; ne« I/O routine 




lOP t 30H 






lOP t 30H 






lOP ♦ 30H 






lOP t 30H 




oe 


'Z3iapou«r 


; 10 string 


XOR 


A 


; sat zero value 


RET 




; return 



and flag 



Figure 8. Source code for the duller lOP In Z-COM. All the Internal routines 
slaply return «1tn the zero flag sat, •hlle tha substantive functions are 
vectored off to tha real BIOS. 



The garbage that appears from address IGF + 3FH to the end 
of the lOP at lOP + 5FFH can be filled with zeros to make things 
look neater. Then the 9 internal vectors have to be modified in the 
same way those in the BIOS were to point to the new address of 
the lOP. Finally, the reconfigured lOP has to be moved from its 
present position at 2800H to its new place in ZC2.COM at 
lAOOH. 

While we are in the debugger doing that, we can also change 
(1) the file control block to load the command processor image 
ZC2.CP (and also the 'not found' message) and (2) the multiple 
command line buffer to run START2. This initial multiple com- 
mand line must also be moved from its old address at IDOOH to 
its new position at 2D00H. Make sure that the second byte in the 
command line buffer points to the page where the real multiple 
command line buffer will be. 

You should then fill all the other buffers with zeros. The 
CPR, RCP, FCP, and ENV modules can be loaded into the 



image. Then the initial path should be set up at address 2BF4H, 
and the wheel byte at address 2BFFH should be set to FFH if you 
want it on. Finally, if you want an error handler to be loaded 
when Z-COM is booted, then patch in the error ommand line 
(for example, "AO:Z33VERR<0> ") at Z3MSG - lOH (2B90H 
inZC2.COM). 

If everything has gone right, and I have not left something 
out or written something wrong, you should be ready to test it 
out. Don't forget to put the command processor image files in 
A15. I know I keep harping on this, but while working on this ar- 
ticle, I forgot to do that on one occasion, and there are now a few 
dents in the table from my fist! 

A Minimum System 

If you ever meet me and feel like having a little fun at my ex- 
pense, just casually make some comment like, "Oh, yeah, I hear 
ZCPR3 has some nice features but that it uses up much too much 
memory." It is a subject that has become a sore point for me 
lately and one that is almost guaranteed to provoke me. To be 
honest, however, the persistance of this false impression is to a 
large degree the result of poor education on our part. No one ever 
talks about minimum ZCPR3 systems; we only describe full- 
blown ones. 

It is true that a full-blown ZCPR3 system uses quite a bit of 
memory. Z-COM takes 1600H = 5.5K bytes of memory out of 
your TPA, a pretty hefty chunk. I like the features that this big Z- 
System gives me, and for the kind of work I do, the smaller TPA 
almost never causes any problem. For me, the benefits far out- 
weigh the cost. 

For some people, however, especially those working with 
voracious memory hogs like database managers and C compilers, 
this is not the case. (It seems to me that someone like Steve Russell 
of SLR should write a good, virtual-memory C compiler like his 
virtual-memory assemblers to prevent this problem.) But the real 
answer is that a ZCPR3 system does not have to have every 
feature implemented. As with most things in this world, the 20/80 
rule applies: for less than 201^0 of the cost, you can buy more than 
iO% of the features. If we eliminate all the variable buffers in the 
last example, we end up with a system that uses only 5 pages 
(1.25K) of memory, a very modest amount. The same system in- 
stalled in the conventional way, with no space required for the vir- 
tual BIOS of Z-COM, would take only 0.75K away from the 
TPA, yet all of the following features would still be there: 

automatic command search path 

fiexibie access to user areas 

multiple commands on a line 

aliases 

shells (including history shell and filer shells) 

extended command processing (including ARUNZ command 

generator) 

powerful error handlers (with command editing) 

terminal-independent operation (TCAP) 

flexible program loading (type-3 environment) 

interprogram communication 

The only things missing are named directories and flow control. 
Some simple flow-control-Iike features could be implemented 
even without the FCP. With all the security features and named- 
directory support removed from the command processor, there is 
room for many more CPR-resident commands, and the ones that 
won't fit can be implemented as virtual residents using the new 
type-3 envirotunent. In summary, a very powerful system can be 
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built with a very small cost in TPA. 

To prove this point (and because it will be useful on those 
rare occasions when I run my database manager), I decided to 
develop a version of Z-COM that would have only the three pages 
of core modules. The memory map is shown in Figure 9. It differs 
in two fundamental ways from all the other maps we have seen: 
(1) it is shorter and (2) the real VBIOS and ZRDOS run at dif- 
ferent addresses than usual. These differences will require some 
new techniques, and we will cover them shortly. 



SystM Coillpon«nt 






2C.COM Address Systea Address 


0200 - 09FF 0800 - OlFF 


ZRDOS 






OAOO - 1 7FF D300 - EOFF 


Virtual BIOS 






1800 - 19fF ElOO - E2FF 


Shel 1 Stack 






lAOO - 1A7F E300 - E47F 


Z3 Massage Buffer 






1A80 - lACf E380 - E4CF 


Externa t FC8 






lADO - 1AF3 E300 - E4F3 


PATH 






1AF< - lAFE E3F4 - E4FE 


Nheel Byte 






1AFF - lAFF E3FF - E4FF 


£n¥lrofl«ent Descriptor 




IBOO - IB7F E400 - E47F 


TCAP 






1B80 - IBFF E480 - E4FF 


Multiple Comtanc Line 




ICOO - 1CCF E500 - E5CF 


External Stack 






ICOO - ICFF E5D0 - E5FF 


Figure 9. Addresses of systea 


CGHponents In the ZCJ.COM file and In the 


target systaai for a 


■ Inlaua 


configuration with no lOP, RCP, FCP, or NOR. 


The f 1 le Is 2E00H - 


1D00H ' 


noOH - 4.25K shorter than the other versions. 



First we have to make Z3BASE.LIB, the equates for which 
are shown in Figure 10. The only subtle change is in the way the 
VBIOS address is defined. Make sure you do not define it in terms 
of any of the modules whose addresses have been set to zero to 
disable them or you will get extremely strange results. 



; Z3BASE.LIB 




rblos e^u 


0e600h 


; First page under BIOS I 


z3c 1 equ 


rblos - lOOh 


z3cls equ 


203 


extsttt equ 


z3cl t OdOh 


; Second page under 


BIOS 


z3«nv equ 


rblos - 200h 


z3«nvs equ 


2 


; Third page under BIOS I 


shstk equ 


rblos - 300h 


shstks equ 


4 


shsize equ 


32 


z3aag equ 


shstk ♦ 080h 


extfcb equ 


shstk t OdOh 


expath equ 


shstk ♦ 0t4h 


expaths equ 


5 


z3«h 1 equ 


shstk t Offh 


; Variable aodulas - 


- all disabled 


zjndirs equ 





z3ndlr equ 





fcps equ 





fcp equ 





reps equ 





rep equ 





lops equ 





lop equ 





; Operating systaa cocuxsnents | 


vblos equ 


shstk - 0200h 


dos equ 


vblos - OaOOh 


ccp equ 


dos - OBOOh 


Figure 10. The ZJBASE.LIB equates for a ulnlMai syttaai that takes 


only 0.75K for the ZCPR3 buffers and 0.5K for the virtual BICS 


required for autoaatlc Installation. 



The basic procedure for creating this system is very much like 
what we have done before. We edit the Z3BASE.LIB file and 
assemble up the CPR and ENV modules (or make the latter by 
patching). There are no FCP, NDR, or lOP modules to worry 
about. We set up the path, the wheel, and the error handler; we 
change the VBIOS file control block to load ZC3.CP for the CPR 
image file and change the 'not found' message to match; and we 
put in the ENV and CPR modules. 

Now we have to face the new complications that arise 
because of the change in size of the file. First we will take up the 
simpler problem — changing the loader code in the first page of 
the file. It normally copies 2C(X)H bytes (from 200H to 2E00H) 
up to the run-time location in memory. Now the image part of the 
file is only 1B(X)H bytes long. If you follow through the loader 
code in a debugger, you should not have too much difficultly 
figuring out what is going on. The hardest parts to trace through 



are the places where the code prints out in-hne strings. You will 
typically see a call instruction followed by very strange code. That 
strange code is the text to be printed. That coding technique is 
very convenient for the programmer (and I use it all the time), but 
it makes disassembly and single-stepping in a debugger much 
more difficult. When you encounter code like this, you have to 
use the dump ('D') display to locate the null (binary 0) that marks 
the end of the string. Then you can continue running using the 
command "G,addr", where 'addr' is the address just after the 
null. 

Anyway, at address 181H you will find the key instruction: 
LD B.C.,2C00H. This must simply be changed to LD 
B.C.,1B00H. That's all there is to it — as far as the loader code is 
concerned. You might wonder why we don't have to change the 
starting address for the load, since it is not the same as before. 
The answer is that Z-COM derives it from the initial jump instruc- 
tion in the CPR image. My first versions of Z33 used a relative 
jump, and I had to put the absolute jump back after one of my 
beta- testers pointed out that it would not work with Z-COM. 

Now we have to face two much more difficult problems: 
both the VBIOS and the ZRDOS modules have to be relocated to 
a new address. How can we possibly do this without source code? 
Well, if you purchased a separate copy of ZRDOS, you have a file 
with a name like ZRDINS.COM with which you can create a 
binary image of ZRDOS that will run at any address and with any 
ENV address. But what if you don't have it? And what about the 
VBIOS part? The latter could conceivably be disassembled, since 
the code is not very long or very complex, but there is a better 
way, one that makes use of the built-in capabilities of the auto- 
install package. 

If you had two computers with different BIOS entry ad- 
dresses, you could perform a standard installation of Z-COM on 
each system. By taking the two ZC.COM files and subtracting 
them in a debugger, you could derive the relocation map. Now the 
question is how we can make two ZC.COMs using a single com- 
puter. 

If you examine the beginning of the code in ZCLD.COM, 
you will see that ZCLD keys its system generation to the address 
of the BIOS warmboot vector at address 0001 , and that is what we 
will base our strategy on. We will fool ZCLD into making us two 
versions of ZC.COM one page apart that we can subtract. 

With my standard Z-COM system running on the Televideo 
803H, the CPR is at BAOOH and the virtual BIOS at DOOOH. 
Thus the vector at address 0001 points to D003H. By entering the 
following commands, we can make the BIOS look as though it 
were at B900: 



POKE B90J C3 03 DO 
POKE 2 B9 



Set up IP D003H at address Sg03»< 
Change .bios vector fron D003 to B903 



Of course, you must use addresses appropriate to your system. 
Any address below the CPR but above the memory used by 
ZCLD should work. 

With this patch in place, everything will be fine so long as we 
do not try to run a program that does direct BIOS calls based on 
the address at 0001 . (If we do? — the system will simply go up in 
fiames!) In case you're worried, the next warmboot will delete our 
patch and restore things to normal. 

Fortunately, ZCLD does not mind being fooled this way. All 
in all, the following sequence of commands will result in two files, 
ZCB8.COM and ZCB9.COM. 



POKE BXI3 CE 03 00;POKE 2 B9;Za0;REN ZC89.C0M-ZC.CCM 
POKE B803 CE 03 00;POK£ 2 B«;2a.0;REN ZC88.C0M-ZC.CflM 
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We can then load both files into a debugger using the commands 



IZC8S.CCH 


; »«t fll« to ZC88.COM 




; r«M In at lOOH (10OH-2DfFH) 


IZCS9.CCH 


; 5«t f 1 l« to ZCa9.COM 


R3oao 


; r«a<) In »t 3tOOH (3100H-50FFH1 



Now from right in the debugger we can assemble a little 
program at 3000H to subtract the ZRDOS and VBIOS images in 
memory block 0A00H-19FFH from the images in memory block 
3A00H-49ffH to give us the relocation map we need. Here is how 
the entry of the assembly code proceeds: 



-A3000 




3000 
3003 


LO DE,3A00 
LD HL.AOO 


; set up pointers to t»o tiles 


3006 
3009 
300A 
3008 
300C 
3000 


LO B.C. .1000 
LD *,(0£) 

sue (HL) 

LD <0£),A 
INC HL 
INC DC 


; nuMber of Pytes to subtract 
; get pyte Iron higher luge 
; subtract pyte froa lo«er laa 
; put result <0 or 1 ) back 
; Increment the pointers 


300£ 


DEC a.c. 


; check count 


300f 


LO A, 8 




3010 


OR C 




3011 
3013 


JR NZ,3009 


; loop through lOOOW bytes 



Enter the command "03000,3013" to run this routine with a 
breakpoint at 3013. If you look at memory from 3A00H TO 
49FFH you will see a pattern of Is and Os. This is the relocation 
map. It indicates which bytes must be changed to shift the 
execution address of the code. 

Now we have to relocate the ZRDOS to run at D300H and 
the VBIOS to run at ElOOH instead of the values 9400H and 
A200H as they are in the image in ZCB8.COM (determined by in- 
spection with a debugger). Thus we have to add an offset of 3FH 
(El - A2) to all bytes where the relocation map has a one in it. So 
we assemble up another little program at 3000H as follows: 



-A3000 

3000 LO HL,3A00 

3003 LD DE.IAOO 

3006 LD B.C. ,1000 

3009 LD A,(D£) 
300A BIT 0,(HL) 
300C JR Z,30n 
300E ADO A,3F 

3010 LO (0£),A 

3011 INC HL 

3012 INC De 

3013 0£C B.C. 

3014 LO A,B 

3015 OR C 

3016 JR NZ,3009 
3018 



; point to relocation byte 

; point to ZROOS/VBIOS we are creating 

: nuaber of bytes to cover 

; get current value of byte 

; see if relocation aep has a 1 in it 

; if not, skip the offset addition 

; add the offset 

; put back the corrected byte 

; increawnt the pointers 

: check the count 



: loop through lOOOh bytes 



Run this program with "03000,3018" and you will have a ZR- 
DOS and VBIOS that will run at the required address. Put them 
in a safe place temporarily while you load in ZC3.COM and then 
move them into the proper place in the image. This completes the 
generation of the minimum system except for one step described a 
little later. 

Although all that work with the debugger took quite a lot of 
space to describe, it is really not that difficult to do. I particularly 
wanted to show it to you because it is a technique that is useful in 
many other circumstances as well (like using MOVCPM to 
r?locate your system in one-page rather than IK increments). 
Now, however, I will show you^a much easier way to accomplish 
the same thing in the case of Z-COM. 

If you load ZCLD.COM into the debugger and trace through 
the code with the 'L' command, you will see how it works. Before 
one gets to the main code, there are two places where checks are 
made. One is to see if the command was invoked as "ZCLD //" 
CO request the built-in help screen. The second test is to make sure 
that you are not trying to run ZCLD from inside a running Z- 
COM system. We could drop out of Z-COM after making the 
changes I am about to describe, but why put up with that trouble? 
The code is testing for the presence of the letter 'Z' in the 
copyright notice inside the VBIOS at offset 42H. At address 249H 
there is a "JP NZ,29D" instruction that takes one to the system- 
building code if no 'Z' is detected. If we change this to an uncon- 
ditional jump, we will effectively disable the test. 
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At 29DH, the code loads the address of the BIOS with the in- 
struction "LD HL.(l)". We know that we want the system to be 
generated at an address llOOH higher than it would be normally 
because of all the modules we removed. Since the normal BIOS 
address was E600H, we want ZCLD to see a value of F700H. To 
accomplish this, we assemble in the instruction "LD HL,F700" a 
direct load instead of an indirect load to HL. We can then save 
away this modified version as ZCLD1.COM. When we run it, it 
very nicely produces a system with a ZRDOS and VBIOS at just 
the addresses we wanted. 

There is one other change I have forgotten to mention The 
jumps in the VBIOS that go to the lOP have to be replaced by 
jumps to the real BIOS at the very same offset as in the VBIOS. 
Thus the jump at offset 06, which was "JP lOP + OCH" would 
become "JP BIOS -H 06HO" . 
Switching from One Version to Another 

What if we are running one of our versions of Z-COM and 
want to change to another one. We can always run the ZCX 
command to get back to CP/M and then load the new Z-COM 
system. This seems unnecessarily tedious. Why can't we just run 
ZC2.COM from the ZCl system? The answer is that Joe Wright 
did not want us to do this. Of course, he was thinking in terms of 
only single configurations, and then there would be no reason to 
run ZC.COM when Z-COM was already running. So, he put in 
some code to protect us from this mistake. 

Now we want to do that very thing! How can we disable the 
safety code? Very simply. It is based on the same check we 
described with the ZCLD program. It looks for a 'Z' at byte 42H 
of the BIOS or VBIOS. If it is a VBIOS, the 'Z' will be there; if it 
is a real BIOS, it would be very unlikely that a 'Z* would be there. 
We could go into the code itself as I described with ZCLD and 
disable the test. Alternatively, we could do something much sim- 
pler (and reversible): go into the VBIOS and remove the 'Z' by 
changing it to something else. A third possibihty, one I implemen- 
ted for the fun of it, is to write a little utility program that finds 
that byte of the BIOS. If it is not a 'Z', it simply returns; if it is a 
'Z', it sets it to zero. Then the next ZCx can load over it. If the 
utility is not run, then the system cannot be overlaid. 

I will suggest one last modification to Z-COM to enhance it 
even further. That is a change to allow alternative versions of Z- 
COM to be loaded without interrupting the flow of commands. 
Thus your memory-hungry C compiler would be invoked with an 
alias the reads something like: ^^ ^^.^ ,.^^^^ 

This alias would load the minimum Z-COM system to give the C 
compiler the most room to work, and then once the compilation 
was finished it would reload the full Z-COM configuration. 1 did 
this with my Z3-DOT-COM/Z-COM combination. The I/O 
Recorder lOP was invoked using an aUas. The aUas would first 
check to see which Z-System was running (that is what I put the 
$M parameter into ARUNZ for). If it was Z3-DOT-COM, then 
alias would load Z-COM before proceeding to load the lOP. I win 
not go through the method for accomplishing this, but I will give 
you a hint. You have to change the loader code in the first page of 
ZCx.COM so that the multiple command line buffer and some 
other system information is not overwritten by the load. 

Plans for Next Time 

Whew! That was quite a session of heavy technical materiaL 
I don't know yet exactly what I will do next time, but I certainly I 
will find a less technical subject. You need a rest, and I need a 
rest. If you have any questions or suggestions, please write or cafl. 
See the ad for Sage Microsystems East for the address and phone 
numbers. ■ 
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Z sets you free! 



Who w« are 

Echelon is a unique company, oriented 
exclusively toward your CP/M-compatible 
computer. Echelon offers top quality software 
at extremely low prices: customers are 
overwhelmed at the amount of software they 
recieve when buying our products. For 
example, the Z-Com product comes with 
approximately 92 utility programs; and our 
TERM III communications package runs to a 
full megabyte of files. This is real value for your 
software dollar 

ZCPR 3.3 

Echelon is famous for our operating systems 
products. ZCPR3, our CP/M enhancement, 
was written by a software professional who 
wanted to add features normally found in 
minicomputer and mainframe operating 
systems to his home computer. He succeeded 
wonderfully, and ZCPR3 has become the 
environment of choice for "power" CP/M- 
compatible users. Add the fine-tuning and 
enhancements of the now-available ZCPR 3.3 
to the original ZCPR 3.0, and the result is truly 
flexible modern software technology, 
surpassing any disk operating system on the 
market today. Get our catalog for more 
information - there's four pages of discussion 
regarding ZCPR3, explaining the benefits 
available to you by using it. 

Z-System 

Z-System is Echelon's complete disk 
operating system, which includes ZCPR3 and 
ZRDOS. It is a complete 100% compatible 
replacement for CP/M 2.2. ZRDOS adds even 
more utility programs, and has the nice feature 
of no need to warm boot (*C) after changing a 
disk. Hard disk users can take advantage of 
ZRDOS "archive" status file handling to make 
incremental backup fast and easy. Because 
ZRDOS is written to take full advantage of the 
Z80, it executes faster than ordinary CP/M and 
can improve your system's performance by up 
to 10%. 

Inatalling ZCPR3/Z-Systafn 

Echelon offers ZCPR3/Z-System in many 
different fonns. For $49 you get the complete 
source code to ZCPR3 and the installation files. 
However, this takes some experience with 
assembly language programming to get 
running, as you must perform the installation 
yourself. 

For users who are not qualified in assemljly 
language programming, Echeton offers our 
"auto-instair products. Z-Comisour 100% 
complete Z-System which even a monkey can 
install, because it installs itself. We offer a 
money-back guarantee if it doesn't install 
properly on your system. Z-Com inckxles many 
interesting utility programs, like UNERASE, 
MENU, VFILER. and much more. 



Echeton also offers 'bootable' disks for 
some CP/M computers, which require 
absolutely no installation, and are capable of 
reconfiguration to change ZCPR3's memory 
requirements. Bootable disks are available for 
Kaypro Z80 and Morrow MD3 computers. 

Z80 Turbo Modula-2 

We are proud to offer the finest high-level 
language programming environment available 
for CP/M-compatible machines. Our Turtxj 
Modula-2 package was created by a famous 
language developer, and altows you to create 
your own programs using the latest technok>gy 
in computer languages - Modula-2. This 
package includes full-screen editor, compiler, 
linker, menu shell, library manager. Installation 
program, module library, the 552 page user's 
guide, and more. Everything needed to 
produce useful programs Is Included. 

"Turbo Modula-2 Is fast.. .[Sieve benchmart^] 
runs almost three times as fast as the same 
program compiled by Turtx) Pascal. ..Turtio 
Modula-2 Is well documented.. Turtio's librarian 
is excellent". - Micro Comucopia #35 

BGil (Backgrounder 2) 

BGII adds a new dimension to your Z-System 
or CP/M 2.2 computer system by creating a 
"non-concurrent multitasking extension" to 
your operating system. This means that you 
can actually have two programs active in your 
machine, one or both "suspended", and one 
currently executing. You may tfien swap back 
and forth between tasks as you see fit. For 
example, you can susperid your telecommunl- 
catkins session with a remote computer to 
compose a message with your full-screen 
editor. Or suspend your spreadsheet to look 
up information In your database. This is very 
handy in an offk:e environment, where constant 
Internjption of your work Is to t>e expected. It's 
a significant enhancement to Z-System and an 
enormous enhancement to CP/M. 

BGil adds much more tfian this swap 
capability. There's a background print spooler, 
keyboard 'macro key' gerierator, t>ullt-in 
calculator, screen dump, the capability of 
cutting and pasting text between programs, 
and a host of other features. 

For best results, we recommend BGil be 
used only on systems with hard disk or 
RAMdisk. 

JetRnd 

A string search utility Is Indispensible for 
people who have built up a large collection of 
documents. Think of how difficult It coukl be to 
find the document to "Mr. Smith" in your 
collection of 500 files. Unless you have a 
string search utility, the only option is to 
examine tltem manually, one by one. 

JetFInd is a powerful string search utility 
whkJh works under any CP/M-compatible 
operating system. It can search for stnngs in 



text tiles of all sorts - straight ASCII, WordStar, 
library (.LBR) file members, "squeezed" files, 
and "crunched" files. JetFind Is very smart and 
very fast, faster than any otfier string searcher 
on the market or in ttie public domain (we krxjw, 
we tested tlwm). 

Softtvare Update Servica 

We were suprised wtien sales of our 
Software Update Servk» (SUS) subscriptions 
far exceeded expectations. SUS is intended 
for our customers wfxi dont have easy access 
to our Z-Node networit of remote access 
systems. At least nine times per year, we mail 
a disk of software collected from Z-Node 
Central to you. This covers non-proprietary 
programs and files discussed in our Z-NEWS 
newsletter. You can subscribe for one year, 
six months, or purchase indlvklual SUS disks. 

Thara'aMora 

We coukjnt fit all Echeton has to offer on a 
single page (you can see how small this 
typeface is already!). We haven't begun to talk 
about the many additional software packages 
arid putjlk^tions we offer. Send in tfie coupon 
below and just cfieck tfie "Requesting Catatog' 
box for more information. 



ttem Naine 


Pnca 




1 ZCPKiConlmMMonPxktg» 


$49.00 


|3diata) 


2 ZCPR3 UtHiliM Packaga 


$89 00 


liOdMka) 


5 Z-Coai lAulo-lnstaa ConiflM* 


$11900 


Hmtar 


Z-Syjwn) 






6 Z-Com "Bars MinHnum* 


$69 95 


(idHhsl 


10BGiiBKl>groun<M>2 


$75.00 


(2diili*) 


12 PUei.C ZnOOS PIus (by itaM) 


$59.50 


(idHk) 


13 Kaypro Z-Systam BootalKa Dak 


$69.95 


(3dMis) 


14 ktorm. MD3 Z-SyMm 


$69.95 


12 disks) 


BoolaM Disk 






16 QOCK-TASK RaaMma 


$248 00 


(3 disks! 


ExKuwe 






17 OusSlanipar Natma/daM 


$49 95 


(1**) 


nainiang 






18 Saltman Updata Sarvica 


$85 00 


(1 yrsubl 


20 ZAS/ZLINK Macro AuamtMf 


$69 00 


ddisk) 


andUnkar 






21 ZOM Oabuggar lor 808(VZ80K 


$50 00 


(idiak) 


HD64 180 CPU's 






22 Translators lor Auaniti4ar 


$5100 


(1 disk) 


Sourcacoda 






23 nEVAS3/4 Diaaaaainblaf 


$90 00 


(idisk) 


24 Spaaal Hams 20 through 23 


$t68.m 


(4 disks) 


25 DSO-80 Ful Scraan Oabuggar 


$129 95 


(Idisk) 


27 Tha Ubranas.SVSUS. Z3Lie. 


$99.00 


(8dWis) 


andVLIB 






2S Qrxmics and Wnkxn Ubrarias 


$49 00 


(KM) 


29 Spaoal Hams 27. 28. and 82 


$149.00 


(9 disks) 


30 Z80 Turt» Madula-2 Languaga 


$89 95 


(idWt) 


SysMm 






40 mputOxpuLRaoofflar lOP (l/OR) 


$39 95 


(Idisk) 


41 Badigraund Pfinar lOP (BPnntar) 


$39 95 


(idlsk) 


44 NuKay Kay RadaAnar lOP 


$39 96 


(IdMt) 




$88 95 


(3dW<s) 


60 DISCAT OW cataugmg synam 


$38 99 


(Idisk) 


61 TERM3CommuncalontSytlam 


$se.oo 


(6 disks) 




$99 00 


(idi*) 


66 JatFnd Smng SmtcK UNIIy 


$49.95 


(I**) 






82 ZCPB3: Tha utnnaa 310 pagaa 


$2995 




83 Z'NEWS Maaslanai, 1 yr subaovMn 


$24 00 




84 ZCPR3 and lOPs SO pagas 


$•95 




85 ZROOS Programmar's Il4anual 35 pagas S8 96 




aa ZSysaam Uaar-s Guida 80 paga tutorial $14 95 





' Inckxtas ZCPR3: Tha Manual 




Echelon, Inc. 

885 N. San Antonio Road, Los Altos, CA 94022 USA 
415/948-3820 (order line and tecli support) 
Telex 4931646 

NAME 

ADDRESS 



ORDER FORM 

Payment to be made by: 

□ Cash 

□ Check 

D Money Order 
a UPS COD 
a Mastercard/Visa: 
« 



ITEM 



PRICE 



TELEPHONE 

D REQUESTING CATALOG 



DISK FORMAT 



Exp. Date 

California residents add 7% sales tax. 
Add S4.00 shipping/handting In North 
Annehca, achjal cost elsewhere. 



Subtotal 
Sales Tax 
Shipping/Handling 



Total 
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68000 

Why use a New OS & the 68000? 

by Joe Bartel, Hawthorne Technology 



Why Work With a New Operating System? 

The small computer market is caught between two ruts 
today. On the small side is the PC and on the large side is Unix. 
The other players missed the boat by having a great (or so they 
thought) interface with nothing behind it to do any useful work. 
To be PC compatible is a dead end. The system is a kludge. 

As developers try to squeeze the last bit of performance from 
the PC there will be problems. It is true that there are several 
million PCs in the world today. This doesn't mean there is a good 
market. Because the market is so large, it is hard (and expensive), 
for a small company to make themselves heard. There are public 
domain or low priced programs for every common appUcation 
that anyone wants. These are hard to compete with. The pressure 
is to continue lowering prices while cutting profits. A business 
person needs to look at what point he can no longer afford to 
remain in this kind of market. 

To break out of this rut a new system architecture is needed. 
Use the PC and clones where they fit but start to forge ahead in 
new directions. This doesn't mean trying to run a PC program on 
another machine. It is possible to emulate an 8086 on a 68(XX) but 
a full PC emulation is not worth while. In every case so far the 
emulation costs more than a PC clone. The interchange of disks 
on the other hand is very economical and easy to do. This protects 
the investment in data and makes it possible to add new machines 
without giving up the old ones. 

The first step to a new architecture is to have a new operating 
system. It must be indpendent of a particular piece of hardware. 
This doesn't mean an operating system that can run on any 
processor. It means not being tied to a limited set of hardware like 
MS-DOS got tied to the PC hardware. The second step is to 
separate the application programs from the operating system it- 
self. To use networks or multiple processors there must be a clear 
distinction between the logical and physical structure of the 
machine. To do otherwise would be to set a limit on what can be 
done with the operating system. 

Bit map graphics and mice are good in some cases but to 
hobble an entire system with tricks that are not often needed or 
used is bad. The original use of mice was to allow people who 
knew httle about computers to retreive information from them. 
They were not ones who had to put information into the com- 
puter or the more experienced users who want low cost and high 
performance. The operating systems like Mac and Atari are com- 
plex to the point where they hinder the development of new 
programs rather than helping. The windows that Microsoft has to 
sell are no better. Look at any stock broker, they have mulitpie 
screens for dealing with different pieces of information at the 
same time, not tiny windows on a single screen. 

A very promising area to look at for the future is multiple 
processor machines. With them, when more users are added to a 
system, more processing power is added also. This makes it 
possible to have multiple access without the slow down problems 



associated with trying to share a single CPU among many users. 
For cost sensitive or low performance users the muliple user ap- 
proach can be used for lowest cost. For applications where high 
performance is important multiple processors can be used. If the 
oi>erating system is independent of the hardware then the same 
program can be used in both cases. 

Another area where multiple processors can be used to ad- 
vantage is to split the operating system into component parts. For 
example the file management system can be duplicated for each 
disk in the system. Then when opening a file on disk A there 
would be no operating system overhead imposed on the system 
running disk B. If a disk is not involved then it would take no part 
in the activity. This allows large numbers of users to all access 
files at high speed if the load is balanced among different disks. A 
remote disk and file system can be Uke a new resource that can be 
easily added and integrated into a system. A company system can 
start small and grow to almost any size without requiring that the 
existing parts be replaced. 

An individual workstation can have graphics and icons or 
not as need or tastes dictate. This will allow some users to access 
the system with icons but not impose that structure on other users 
of the system. It also means that some users could have windows 
and others could have more than one screen. Some users could 
have a local floppy disk or printer too. This approach to things 
opens a wide area of possible designs for working. 

It is time to start planning for the future while the present 
generation of computers is still adequate for today. If we don't 
start now we won't have the next generation when we need it. At 
Hawthorne Technology we are working on new ways of doing 
things. All of our programs are compatible with K-OS ONE at the 
system call level. Our hardware varies a lot. We even use PC 
Clones for some things. But any program that uses K-OS ONE 
system calls to access the hardware, and doesn't depend on special 
terminals, will run on any K-OS ONE system. We intend to keep 
this compatibility in the future for all systems whether 
distributed, multitask or single task. You can join us in this by 
using K-OS ONE or by writing applications to run with it. The 
number of people using K-OS ONE is increasing every day. There 
is a growing market for Languages and application software. 
Anyone interested in doing a {package should contact us. We will 
help out in any way we can. 

Why Use a 68000? 

Most of the time it is not easy leaving an old processor and 
going to a new one. On the old processor you are an expert and 
know all the small things that can and will go wrong. When you 
switch to a new processor you have to start all over again. So why 
switch? 

The 8 bit machines are limited and there is little room to grow 
with them. The 68000 on the other hand has enough growth 
potential to last for many years to come. There are other 32 bit 
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processors, but none of the others offer the same advantages as 
the 68000. 

After you start working with it, you will find that building 
hardware with the 68000 is as easy or in many cases easier than 
building the same thing with an 8 bit processor. For small con- 
troller projects there is even an 8 bit bus version (the 68008) that 
comes in a 48 pin package. The 68000 and 68008 both have an E 
clock signal output that allows you to directly connect any 
peripheral device from the 68xx or 65xx families. 

In most cases, the cost of doing the software for a project is 
many times the cost of the hardware. All of the software cost has 
to be paid for before the first unit is shipped. Hardware is paid for 
as units are sold. The 68000 is easier to program than the smaller 8 
bit machines. The mistake many people make is the idea that just 
because you have 16 registers you have to use all of them. You 
don't. Just use the parts that you want and ignore the rest. After 
you have some experience you can start using the other comman- 
ds and addressing modes. 

Inline code and programs in general can be as small for the 
68000 as for any 8 bit machine. The reason many current 
programs are so large is that they were written for the 8086 
processor family, which is sloppy and many of them are written in 
higher level languages with compilers that don't generate very 
good code. What was several lines of code for a Z-80 or 6502 can 
often be done with a single instruction in the 68000. 

The main limitation for the 8 bit machines is the small 
memory space and the small size of the registers available. If you 
want to work with more than 64k of memory you have to have 
registers that are big enough to hold an address. This means that 
without a full 32 bit register you will spend lots of time and effort 
working on address pointers that sould be trivial. 

The 68000 is much faster than an 8 bit machine for arithmetic 
and full size pointer manipulation. For simple 8 bit operations 
like those encountered in text editors it is true that the Z-80 is very 
hard to beat. But if you need more memory to edit a large file or a 
lot of features are added to the editor, things become difficult. 
With a large address space you don't have to page parts of the 
program into memory from the disk. For spread sheets and 
arithmetic, the larger register size of the 68000 is faster by far. 

When you look at the small cost difference between the 
68000 and the older machines the choice becomes easier. Keep the 
8 bit machines for existing products or for very high volume or 
where there is not much programming involved but for new 
products go with the 68000. it is easier to program, faster, and has 
more of a future. 

Starting With HTPL 

Welcome to HTPL programming. If you are familiar with 
Pascal, Modula or Forth then HTPL will have many parts that 
you already know. From Forth we borrowed the use of RPN 
notation for expressions. From Pascal and Modula we borrowed 
a structure. HTPL is good for writing small, fast programs. It can 
also be extended to fit any special needs in other programming 
areas. 

To start learning any new language it helps to see a complete 
example in that language. The example can then be related to the 
same program in a language you are more familiar with. This 
example is a simple but complete HTPL program that displays 
' ' Hello World ! " on the console. 

The first line is a comment. When anything is placed in 
parenthesis in an HTPL program it is treated as a comment and 
ignored. The word "root" indicates that this is not an overlay, 
and tells the compiler to include the runtime library with the 



generated object code. The word "program" tells where the 
program will start executing when it is run. The main part of the 
program continues until the first "end". The second "end" in- 
dicates the end of the entire file being compiled. The wc Is in the 
double quote marks are a string constant. When a string constant 
is encountered the contents of the string are saved in a data area 
and the address of the string is placed on the evaluation stack. 
The word "sprint" is a call to a run time library routine to print 
the null terminated string. The 13 is the numeric value of a 
carriage return character. It is pushed on the stack. The word 
"putc" is another library routine that prints the low 8 bits of the 
top of the stack as a single character. The "10 putc" sends out a 
linefeed character. 

Sample Program 

root 
program 

"Hello World! "sprint 

13 putc 10 putc 

end 
end 

This is a complete HTPL program. When it is run it will 
display "Hello World!" on the terminal. Most of the tokens are 
refered to as words in HTPL just like in Forth. 

Editor's Note: When this file is compiled, the executable BIN 
file including the run time library is only 1, 446 bytes. This is much 
smaller than a similar Pascal or C program. 

HTPL Compile and Run 

To compile and run an HTPL program you first write the 
program using any editor. The compiler assumes that all charac- 
ters have the high bit a zero. The output of the compiler is an 
executable binary file. 

To compile a program type HTPL at the command line 
prompt. After the compiler is loaded it will prompt for the name 
of the first input file. Next it will prompt for the name of the out- 
put file. Any extension can be given for the output file but the 
command processor will only try to load and execute files that 
have the extension ".BIN". Next you will be prompted for op- 
tions. If you enter an "N", there will be no listing of the source 
code as the program is compiled. If you put an 'S", there will be 
no symbol table listing after the program is compiled. The options 
can be given in any order. The compiler reads the source program 
and any files involved twice. The run time library hex file "HT- 
PLRTL.HEX" must be on the default drive for the compiler to 
find it. An overlay doesn't include the runtime library so it is not 
needed. You can include as many source files as you want at com- 
pile time so each source file can be kept small to be easier to edit. 

Stack NoUtion 

The commands in the manual have a comment describing the 
stack before and after the call to the routine. This is necessary 
because in a stack oriented programming environment the 
programmer has to keep track of the stack. Errors in the size of 
the stack is perhaps the most common kind of error made. 

The letters or words before the "~" are the contents of the 
stack before the call. The top of the stack is on the far right hand 
side. The words or letters after the "~" are the contents after 
returning from the routine or after the word is executed. If a word 
appears before and not after it has been used up. The number of 
items before and after the call indicate how the stack will grow or 
shrink when the routine is run. If a routine calls itself then this 
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can be used to estimate how many levels of stack will be required 
to run the program. 



EXAMPLE: a b — c 








Shows the stack, change: 


b 




top 




a 


c 












bottom 




stack. 


stack 






before 


after 





What is RPN, and Why Would You Want to Use It? 

There are three different ways to mix operators and the 
things they operate on: prefix, infix, and postfix. These simply 
mean that the operator comes before the operands, between the 
operands, or after the operands. Most of the common 
languages like BASIC, C or PASCAL are 
infix languages. LISP is the only common 
prefix language. Postfix languages, 
refered to as RPN (Reverse Polish 
Notation), are represented by Forth, 
PostScript, and HTPL. The Teco editor 
used RPN. Adding machines all use RPN 
and most printing desk calculators use 
RPN. Each notation has its adherents. So 
why use RPN? 

The compiler for an RPN language is 
smaller and simpler than the compiler for 
an infix algebraic language. A large por- 
tion of most compilers is a syntax analysis 
routine that converts the source language 
to an internal RPN format. If the source 
is RPN this step is eliminated. When a 
subscripted variable is referenced a lot of 
code needs to be generated to calculate the 
address to use. In RPN these calculations 
are explicit rather than hidden. For ex- 
pressions, all an RPN compiler needs to 
do is push any operand on the evaluation 
stack and call or generate code for any 
operator. 

In an RPN language, user created 
operators look the same as the built in 
operators. When a subroutine package is 
used to extend an infix language the sub- 
routine calls are very different from the 
built in operators. If the extensions look 
the same as the built in operators they are 
easier to use and the whole program has a 
more natural look about it. It is easy to 
create a special set of words for graphics, 
statistics, mathematics or data base 
programs. By the time a conventional 
language has been extended very far it 
starts to look more like LISP than 
whatever it started out as. An RPN 
language in contrast looks the same no 
matter how far it is extended. 

An RPN language is much sitnplcr to 
learn than an algebraic language. There 
are no rules of associativity or precedence. 
The operations are done in the order 
specified. In the C language there are 14 
levels of precedence. Some associate left 



to right and some the other way. With RPN languages things are 
much simpler. If it is data it goes on the stack. If it is an action 
word, the action happens. 

In an RPN language the programmer has more control over 
what kind of code is produced. The sequence of operations is 
given by the source code. You don't have to worry about the 
compiler rearranging the order to get better code. Even when 
using an optimizing compiler you are assured that the operations 
will be executed in the sequence given. 

RPN languages are more flexible with the way arguments are 
passed to subroutines. You can pass parameters by value and 
parameters by reference in a single call. 

The items on the stack become abstract items. They can be 
used as values or addresses. They can be used as byte pointers, 
word pointers, long pointers, pointers to structures, or pointers to 



68000 SINGLE BOARD COMPUTER 

$395.00 

32 bit Features/ 8 bit Price 



-Hardware features: 

• 8MHZ 68000 CPU 

* 1770 Floppy Controller 

* 2 Serial Ports (68G81) 

• General Purpose Timer 

* Centronics Printer Port 

• 128K RAH (expandable to 
512X on board.) 

• Expansion Bus 

• 5.75 X 8.0 Inches 
Mounts to Side of Drive 

* +5v 2A, +12 for RS-232 

* Power Connector same as 
disk drive 

Add a terminal, disk drive 
and power, and you will have 
a powerful 68000 system. 




-Software Included: 
' K-OS ONE, the 68000 Operating 
System (source code included) 

* Command Processor (w/source) 

* Data and File Compatible with 
MS-DOS 

* A 68000 Assembler 

* An HTPL Compiler 

* A Line Editor 



ASSEMBLED AND TESTED 0HL1 $395.00 



K-OS ONE, 68000 OPERATING SYSTEM 

For your existing 68000 hardware, you can get the K-OS ONE 

Operating System package for only $50.00. K-OS ONE is a powerful, 

pliable, single user operating system with source code provided 

for operating system and command processor. It allows you to 

read and write MS-DOS format diskettes with your 68000 system. 

The package also contains an Assembler, an HTPL (high level 

language) Compiler, a Line Editor and manual. 



SHIPPED OM AH MS-DOS 




DISK $50.00 



HAWTHORNE TECHNOLOGY 

8836 S. E. Stark 
Portland, Or 97216 
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strings. Different numbers of parameters can be used by the 
called routine depending on what is found on the stack. A 
procedure can return a varying number of results depending on 
what happened. Conventional languages don't offer this kind of 
flexibility. The 68000 is a very good processor to use with an RPN 
language. All eight of the address registers can be used as stack 
pointers. In the other contending micros you have only a single 
stack pointer and that is used for return addresses. The 68000 also 
has a very effective set of opcodes that make for small efficient 
programs. 

HTPL has very low overhead on procedure calls. In HTPL 
there is only a BSR or JSR to get to the procedure and an RTS to 
get back from the procedure. Any arguments used by the 
procedure are found on the evaluation stack. This means that 
there is no need for an explicit transfer of arguments. 

Many new languages like Post Script are using RPN because 
as a subject gets more abstract the use of a stack to hold operands 
becomes more convenient. The algebraic languages were derived 
from math equations. When computing is less numeric in nature, 
it is useful to have a stack for a short term memory to hold what is 
being worked on. 

There are not many books or articles on theory for RPN 
languages. In many cases this is because writers write about things 
that are easy to write about. If you look at any book on compilers 
you find good coverage of syntax and very little coverage of code 
generating. If you write a compiler you spend lots of time on the 
code generating and relatively little on the syntax. 

Why Not Forth? 

Because Forth is the best known of the current RPN 
languages many of it's quirks are assumed to be in all RPN 
languages. While some of these disadvantages may be true with 
Forth, they are not neccessarily true about all RPN languages. 

RPN and threaded code are not the same thing. RPN is a way 
for a programmer to describe the problem to the computer. 
Threaded code is a technique for generating object code. 
Threaded code has been popular for Forth on microprocessors 
because it allows you to create a very fast interpreted instruction 
set. For 32 bit machines like the 68000 there is no real need to use 
threaded code. 

Incremental compiling is also a technique that is often 
associated with RPN languages. This was a technique used to 
create an interactive environment without the slowness of a con- 
ventional interpreter. Many RPN languages are now compiled. 

As you can see, RPN languages do not need to be feared. 
The weak points of popular RPN languages have given this 
method a bad name. One it does not rightly deserve. It may seem 
like an unnatural method at first. This is due to early mathamatics 
training. Anyone who has learned to use a 10 key adding machine 
has learned to use RPN with postfix operators. Most adding 
machine operators wouldn't recognize the terms, but after their 
first couple of weeks training, they don't even think about the or- 
der they enter the information into the machine. Ask someone 
you know who uses a 10 key by touch, what order they put the in- 
formation into the machine. If they don't have a machine they 
can try it on to find out, they will have to think it through 
keystroke by keystroke. The actions have become automatic. It 
isn't so unnatural after all. 

HTPL Programming Techniques When starting to use 
any new language there are lots of little tricks and 
techniques that you learn to make it easier and faster to 
write programs. Some of these are very dependent of the 
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kinds of programs that are being written and some are of a 
much more general nature. For many languages there are 
collections of algorithms. These can be used to write a 
good sort program or to manipulate a data structure. 

HTPL is a stack oriented language. If a stack is not a 
familiar thing, code can be produced by making a literal 
tranlation of simple algebraic code. Frequently used code 
sequences can be given a name and made into a procedure. 
The use of many small procedures results in a slight speed 
penalty but tends to make the object code generated a little 
smaller. 

Because a stack is so easy to use, there is a tendency to 
try to do too many things on the stack and save too many 
values there. You should avoid ever having more than four 
values on the stack at any time. Saving a value in a tem- 
porary variable is not that hard. Having the wrong number 
of items on the evaluation stack is probably the most 
common error that occurs in RPN languages. The reset 
command is used to reset the return and evaluation stacks. 
Sometimes I use reset as a safty mechanism. When I'm not 
sure if the stacks are OK I use it to force them into a known 
good condition. 

Strings and Characters 

Many of the program modules that 
are used in the K-OS ONE system deal with strings or character 
manipulation. In the early days of computing, the processing of 
numbers was most important. Now it is more important to be able 
to easily manipulate characters. The stack is used to pass single 
characters or the address of a string. HTPL uses the C convention 
where a string is a group of bytes that ends with a null or zero 
byte. A string is referenced by pointing to the first charcter of it. 
Also by convention, a valid pointer can never be equal to 0. That 
is refered to as a null pointer and it means that it doesn't point to 
anything. Because all stack values are 32 bits long, a string can be 
kept any place in memory. 

The first two routines below deal with adding a character to 
the end of a string that is being built. In both cases a pointer is 
used to save the character then the pointer is incremented so it will 
be ready for the next use. In some cases it is possible to have 
characters and pointers on the stack. In most cases however it will 
be easier if either the character or the pointer is in memory. A 
short assembly routine can be added to the run time library to do 
many of these things if they are used a lot. 

In the first case, the destination pointer is on the stack. The 
item is placed on the stack. Then the over is used to make a copy 
of the address to store the character. The ! 1 uses the character and 
the copy of the pointer. The + 1 then increments the pointer for 
next time. 

In the second case, the destination pointer is in a variable and 
the character is on the stack. First we get the pointer on the stack. 
We then duplicate the pointer so that we will have a copy of the 
pointer as it is. We increment the top copy and store it back in the 
variable that holds the pointer. The other copy of the pointer that 
wasn't incremented is used by ! 1 to store the character. 

Add a character to a string: 

1. if the destination pointer is on the stack: 
@item over ! 1 +1 
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2. if the item is on the stack: 
Spntr dup +1 Ipnter !1 



Get the next character using a pointer and return it: 
@pntr dup +1 !pntr @1 

Change lowercase letters to uppercase letters: 
if dup 'a' ' z' range then 32 - end 

Looking for first space, (pointer is on stack): 
while dup (?!''<> do +1 end 



I would also like to see more articles en 
interfacing speech chips (SP0256) and 
sound chips (AY-3-8210/8212) to various 
buses, using IBM keyboards and monitors 
with non-IBM equipment... (Which 
reminds me, pin outs and signal descrip- 
tions for the IBM keyboard, monitors, 
and other peripherals would be extremely 
useful to us non- IBM types to support in- 
terfacing attempts.) 

L.S. 



Reader's Feedback 



(Continued from page 4) 

take a 64 pin header and replace the Z80 
with a HD64180Z, if the HD64180Z will 
run at 4 MHz. I think my 64K chips will 
baulk at 6 MHz. 

If this works I plan to remove the 64K 
chips later and replace them with 256K 
chips and bring the system up to 6 MHz 
along with new ROMS. 

At this point I am a systems program- 
mer. Also am learning to type and will try 
to learn assembly language programming. 
There is a lot to crowd into my later life. I 
am 72 now. 

What do you think of the idea? 

Any help you can give me will be greatly 
appreciated. 

Hiram Desantis 

1896 Keewin Ave. N.E. 

Palm Bay, FL 32905 

Ho'w about some of you hardware 
gurus giving Hiram a hand on this project. 



Disk Formats 

The big issue around here is disk for- 
mats. Number one is getting other 
people's files' moved to the Macintosh 
network, from IBM, CP/M, HP 3 'A', 
Tandy 100 3'/2', etc. Number two is 
keeping all the files on the CP/M systems 
accessible when 8" SSSD seems to be ob- 
solete and the CCS 2422 (at least mine) 
won't read/write the Ampro or Kaypro 
formats everyone seems to be using for 
disk exchange. 

If Ampro format is the new CP/M 
"standard," how about publishing all the 
details & hints on how to read it? Or a 
series of programs to force the common 
controller chips to read it (1793, 765A, 
etc) and only require the proper I/O ports 
to be patched in? 



Maybe my problem is trying to use my 
Teac 550 (dBM-AT style 8" compatible) 
drives in their 5" 300 rpm mode, instead 
of regular 40 track drives... Has anyone 
made this work? 

L.A. 



Jay Sage Fan 

The past year has been terrific! Jay Sage 
is a real boost. His insight and the 
brilliance of his work is monumental. 
Also, his understanding of those of us 
with small TP As (Osb 1 , hard drive) is an 
uplift. 

I have used his new "SUB" to make 
programs leave ZCPR33, run in full TPA, 
and then return to ZCPR33, fantastic! 

Keep Clark Cdkins writing about 
debugging and Thomas Hilton's 
educational articles. 

Thanks for a terrific year. 

A.W. 



ZMUser 

I have two systems — both Z80 based 
My "main" system is a TRS-80 Model 
II with 256K memory, two 8" I Mbyte 
floppies, and a high resolution graphics 
board. I run OASIS, a multi-user OS on 
this computer. My other system is a 
Telcvido 806 with two 5 V* ' fioppies, run- 
ning CP/M 2.2x. 

I would like to see articles on inter- 
facing hard disks to SCSI con- 
trollers — compatibilitiy of various SCSI 
based controllers with various hard disks, 
command sets for the controllers, exam- 
ple drivers, comparisions of different con- 
troller/disk combinations for speed and 
ease of use, etc. 



Miscellaneous Reader Comments 

How about a wire wrap video board for 
the IBM PC Bus?. Possibly using one of 
the new graphics controller IC chips. 
Suggest you drop CP/M & Z80. 

Would like to see more hardware and 
software articles for MS DOS, especially 
AT systems. 

I am renewing because you have more 
articles on MS DOS. I am interested in 
understanding MS DOS so I can write 
programs such as device drivers or other 
enhancements to MS DOS. 

Like C.D.M. (Reader Feedback, Issue 
#27), I was afraid that you might be 
following in the footsteps of Com- 
munications and Electronics, which I once 
thoroughly enjoyed because of its blend 
of hardware and software material 
(generally not too complex for my 
capabilities). 

I, was about to drop my subscription but 
decided to wait for issue #27 before I 
made my decision. Happily (as owner of 
an SB- 180) Jay Sage's column appeared 
for a third consecutive issue with promise 
of continuing regularly. This alone wa 
enough to make me reconsider. Also Jo 
Schneider's article on the HD64180 pt 
the icing on the cake. 

Please don't forget us hardware hob 
byists (expen though we may not be). 

I am still interested in CP/M stuff (Nor- 
th Star). I recently acquired a Sage II and 
would be interested in an article on how to 
install K-OS ONE on it. 

My systems are Ampro Z80 Little 
Board (lA), STD Homebrew, expanded 
Little Board on STD Bus. 

Just in — Hawthorne Little Giant. It's 
gonna need hack ports of: VDO, 
Disk7/Sweep, NULU, Small C, Super- 
zap, Fbad, MDM740, Unera, Vfiler, 
DDT/SID, Config, Multidsk. 

I'm designing/programming boards for 

(Continued on page 41) 



The Computer Journal / issue #29 



35 



Detecting the 8087 Math Chip 

Temperature Sensitive Software 

by E. Clay Buchanan III 



There I was happily hacking in 8086 assembly language when 
a customer phoned to describe a problem he was having with one 
of my company's older graphics products. The symptoms he 
described were unbelievable. The same program which ran fine on 
an XT or PC would fail on about one third of all the ATs at the 
customer site. The customer had gotten the program to work on 
one or two of the failing ATs by changing their motherboards 
although one AT required three different boards before one 
worked. In addition one AT would fail if recently powered up but 
once it had been running for 30 minutes or so it worked! So the 
customer asked me "What's the problem?" 

My answer was simple "Sorry, I can't answer your problem 
right now, I have to jump out a window first." Fortunately I was 
saved at the ledge by a wise sage who told me that symptoms like 
these in graphics or math software are almost always the result of 
the program improperly sensing the presence or absence of the 
8087 or 80287 math coprocessor. Since my DOS technical 
reference manual doesn't state how to detect the presence of an 
8087 and the AT technical reference doesn't seem to mention it 
either I looked at a very good book called "The IBM PC from the 
Inside Out," by Murray Sargent III and Richard L. Shoemaker, 
copyright 1986, ISBN 0-201-06918-0, Published by Addison- 
Wesley. This book has a great deal of hardware information in it 
which includes the 8087 math coprocessor. On the cover is a sub- 
title "Includes the PC AT" and with its wealth of logic diagrams 
and TTL circuit descriptions it seems the authors must have an ex- 
tensive background in hardware design. On page 167 is a simple 
program to detect the presence of an 8087: 



Ists87 da 



Offh 



Chke7: fnlnit 

MOV cx,64h 
chk872: loop chk872 

fnstSK ists87 

ret 



;Try to initialize the 8087 or 80287 
;*»it long enough to let It finish 
;(ifs It's there) 
; Store status word 



The logic of this code seems perfect. Order the 8087 to store 
its status word in memory. If the store instruction changes 
memory then an 8087 must be present. There is only one problem. 
This little piece of code failed on one of the three "True Blue" 
IBM ATs I tried it on. It worked on every PC and XT I tried. For 
reasons known only to hardware designers one of the ATs I ran 
this on changed memory from Offh to Oddh even though no 8087 
was present. As a result the above code would improperly detect 
an 8087 and thousands of floating point operations would go 
zooming off to a nonexistent chip. From there its just a matter of 
time before an FWAIT instruction or some other combination of 
floating point instructions hang the AT or result in a wild jump 
into interrupt vectors. Clearly I was looking at a "feature" of the 
AT motherboard design. 

I must emphasize Mr. Sargent and Mr. Shoemaker are quite 
knowledgeable on the AT motherboard. Page 230 of their book 
has a section titled "IBM PC AT System Board" with a 



schematic. Whole sections of the book are devoted to the use of 
the 8087. All in all it's a first rate book. But somehow these exper- 
ts were a little off in detecting the math coprocessor. Everything 
was pointing to this as the problem so I began looking through 
our product's code to find where we detected the presence or ab- 
sence of the 8087. 

The product was written almost entirely in 8086 assembly 
language but some floating point code was written in Lattice C. I 
don't know the exact version of Lattice used but it must have 
been before version 2.14. Lattice was then advertising that its run 
time libraries automatically detected the 8087 and would use the 
chip if present or emulate it if absent. Stepping through the code 
with debug I quickly came across the sensing code. It was as 
follows: 



toy word ptr 101341, Offffh 

fsts» 101341 

aip xord ptr 101341, Offtfh 



Almost identical to the code in Sargent's and Shoemaker's 
book and consequently subject to failing on one third of the ATs 
I tried it on. When I relinked the product with version 2.14 of the 
Lattice compiler the program worked on all the ATs I tried it on. 
Stepping through the code showed the sensing routine had been 
slightly changed to: 

inov nord ptr 10140). Offffh 

fstsK 101401 

test Kord ptr 101401, 0b8bfh 

Changing memory is no longer enough to indicate an 8087. A 
more complex data pattern is now required. Obviously the Lattice 
engineers had detected or heard of the bug and changed their code 
for version 2. 14. When I ran the above code on one AT the Offffh 
value changed to 3eddh but the test for Ob8bfh worked and the 
routine correctly identified the absence of an 80287 chip. 

Just to see if anyone else had noticed this problem I went 
through my back copies of Dr. Dobb's Journal and found a 
reference to the 8087 and 80287 in the September 1985 issue. The 
16-BIT Software Toolbox section of that issue gave the code to 
detect a math coprocessor. It was almost the same as the Lattice C 
routine except it used a fnstcw instruction and then checked for a 
value of 03h as the high byte of the stored word i.e. variable + 1 in 
memory. The article warned about a difference between the 8087 
and 80287. Apparently the 8087 stores a value of 03ffh if present 
and the 80287 stores a different value in the low byte. To be safe 
the article recommends checking for the 3. The article says this is 
the "accepted strategy" for detecting a coprocessor. 

Where is IBM in all this? Isn't there an IBM approved way to 
detect the presence or absence of a math coprocessor? Yes, there 
is. But don't expect to find it where everyone will look. I expected 
to find a line in the AT technical reference manual that read 
something like "coprocessor, detection of." But nooOOOoo. 
That would be too easy. Ditto for the DOS technical reference 
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manual. I finally obtained a technical note from IBM on how to 
doit: 



Int llh 
and ax, 2 
j 2 ■P_"ot_l ft 
nop 



; Jump I f no aath coprocessor 
;Has coprocessor 



■ip_not_i n : 



IBM's solution is clear, use BIOS interrupt llh to detect the 
8087. The note goes on to say "This procedure applies to the PC, 
XT, and Portable, as well as the AT. On the PC, XT, and Por- 
table the user must have set the switch on the planar board 
properly per published instructions. On the AT the Power On 
Systems Test (POST) code takes care of this initialization." 
Finally the note says "Other techniques to check for the presence 
of a math co-processor may yield unreliable results and, 
therefore, are not supported by IBM." No kidding. 

I'm sure Lattice knew about int llh when they coded their 
run time floating point library. Why didn't they use it? Obviously 
I can't be certain but I can guess since I write compiler run time 
libraries for a living. A constant goal of any library is to be por- 
table. Write the routine once, debug it once, and then forget 
about it. Making BIOS calls in your library introduces a depen- 
dency. Your library now assumes an IBM compatible BIOS to 
work correctly. What if you're porting to a clone that doesn't 



have an int llh? A BIOS interrupt takes more time than a sutus 
word store and besides, a store and compare seems so simple and 
self contained. Who would have thought IBM would design a 
computer that responds to instructions to nonexistent chips? XTs 
and PCs don't. Most ATs don't and although I v.asn't able to 
verify it the customer was certain some ATs were temperature 
sensitive. So the choice is up to you. Personally I'm a big ad- 
vocate of nonjudgemental design. Use or don't use the BIOS in- 
terrupt depending on your needs. Just be aware that IBM accepts 
no substitutes for int 1 1 h. 

If you come across software with these symptoms don't just 
set a breakpoint at the int llh routine and assume that because 
some of your software is doing BIOS calls to check for the 8087 
all of the software uses int llh. In our product two different C 
compilers were used and one used int llh while the other used 
status word stores. 

In the end I replaced our product's status word store instruc- 
tions with int 1 Ih. I decided to adhere to the IBM standard. This 
time at least. 1 take comfort in hearing that even Intel has trouble 
with the interface between the 80386 cpu and the 80387 floating 
point chip. It seems Intel is coming out with a new step of the 
80386 to fix "minor" glitches in the math coprocessor interface. 
Keep your debugger handy and your computer cool. You never 
know when a floating point bug is creeping around. ■ 




• Clocks — We need articles discussing the pros and cons of various time keeping 
methods. I have choosen to use the KCT 2time-l because I feel it is best for my aplications, 
and I have an article in preparation. 

Submit your clock related programs and ideas - many different approaches are bet- 
ter than just one. 

• 68000 - TCJ is planning extensive coverage of the 68000 series and we need articles on 
assembly language programming, interfacing to peripheral chips (parallel and series I/O, 
disk controller, graphics, etc.), and general articles on the 68000. 

• CUQ Disk Reviews — The C User's Group library contains many useful disks. I am 
reviewing several disks, but need help because there are more than I can handle alone. 

Contact TCJ if you would like to review CUG disks. 

TCJ is User Supported 

If You Don't Contribute Anything.... 

....Then Don't Expect Anything 
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Floppy Disk Track Structure 

A Look at Disk Control Information & Data Capacity 

by Dr. Edwin Thall, Wayne General & Technical College 



The floppy diskette, a popular mass-storage medium, con- 
tains more than just the user's data. The MS/PC-DOS 360K for- 
mat delegates approximately one-fourth of usable diskette space 
for purposes other than data. Diskette control information is 
required to locate, separate, and check validity of data. In this ar- 
ticle, I analyze the diskette track structure generated by the har- 
dware of IBM PCs and compatibles. I will demonstrate how con- 
trol information can be displayed and describe how it influences 
data capacity. 

Track Stnisture 

The track organization of the 360K format is illustrated in 
Figure 1. Each side of the 5Vt inch double density diskette 
possesses 40 concentric tracks extending from track on the 
periphery to track 39 near the hub. Although more space is 
available for storage on outer tracks, the hardware requires a con- 
stant number of bytes for all tracks. This number, approximately 
6,200, is determined by the size of the inner tracks. 




TftACXO 1 2 3 



nfonLTnekl 



• (3MK fonut) 



The format procedure creates the track structure needed to 
store and locate data. A 146 byte track preliminary begins im- 
mediately after the index hole and consists of: 



60 bytes 4EH 
12 bytss 00 (sync field) 
4 bytes C2C2C2FCH (eddress 
50 bytes 4EH 



to the end of the track with 4EH. Sectors, the fundamental unit 
of diskette information, represent the smallest part of a track that 
can be read or written. 

What's In A Sector? 

The exact structure of a newly formatted sector is provided in 
Figure 2. Besides data, sectors contain 62 bytes of control infor- 
mation. Every sector has two major components: the iden- 
tification (ID) field and the data field. As the name suggests, the 
data field storehouses user data and is the most important part of 
a sector. The ID field holds the information needed to locate sec- 
tors. Let's examine sector components in detail. 



Sector ID Field: 



Field Separator; 
Sector Data Field: 



Sector Gap: 



12 bytes 

4 bytes 

4 bytes 

2 bytes 



00 

A1A1AIFEH 
CHRN 
CRCl 



(sync field) 
( ID address mark) 
(sector ID) 
(error check) 



(sync field) 



22 bytes 4EH 

12 bytes 00 .,,... . 

4 bytes AlAtAIFBH (data address mark) 

512 bytes F6H (data) 

2 bytes CRC2 (error check) 

80 bytes 4EH 



Figure 2. Structure of nearly forMtted sector 



The ID field begins with a sync field followed by the ID ad- 
dress mark. Sync fields, 12 bytes of 00, forewarn the coming of 
address marks. You are probably aware that information is 
recorded in serial bit stream (1 and 0) on the coated surface of a 
diskette. When writing data, a change or "transition" is represen- 
ted by "1" and lack of transition by "0." Double density disket- 
tes, based on the MFM (modified frequency modulation) en- 
coding scheme, store data in bit cells large enough to hold two 
transitions. The extra transition, known as a "clock," marks the 
start of a cell. A large string of zero bits (lack of transition) can 
prevent the detector from locating the beginning of a cell. Clock 
transitions, stored between consecutive zero data bits, identify the 
start of a cell. 



01 00 01 00 10 10 10 01 
Figure 3. MFM encoding scneae for AIH (1010 0001) 



Nine equally spaced sectors follow and unused area is filled 



To demonstrate how clock transitions are distributed, con- 
sider the bits inAIH(10I0000I)as they are stored in eight con- 
secutive cells (see Figure 3). The first bit in every cell specifies the 
clock and the second bit data. Note the clock transitions (arrows) 

Dr. Edwin Thall, Professor of Chemistry at The Wayne 
General and Technical College of The University of Akron, 
teaches chemistry and computer programming. 
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between consecutive zero data bits. Address marks are not given 
clock transitions and vary physically from other data bits. The 
four-byte field AIAIAIFEH would normally possess nine clock 
transitions, but contains none when written as the ID address 
mark. This unique pattern enables the computer to distinguish 
address marks from everything else. 

The CHRN follows the ID address mark and is the most im- 
portant component of the ID field. Formatted sectors are iden- 
tified for future read/write operations by this four-byte field. The 
four CHRN parameters specify: 



C Track number 

H Head number 

R Sector number 

N Sector length 



(0O-27H) 

(00-5 I de 0, 01 -side I ) 
(01 ,02,03,...) 
(128*2**N, N«0,I,2,3.4,5) 



The fifth sector on track 07, head 00, and holding 512 bytes of 
data is identified by 07000502. 

Cyclic redundancy checks (CRC) test the correct reading of a 
sector's identification (CHRN) and data block. The technique 
depends on an algorithm to verify the accuracy of data written to 
a sector. IBM and compatibles rely on the CRC-CCITT error 
detection code. This technique is based on the polynomial: 

G(X) ' X**16 + X"I2 + X"5 t 1 

The equation may be restated with 17 binary coefficients 
(under I Ined) as: 

l(X**16)+O(X**15)+0(X"14)+O(X**13)tl(X**12)t0(X**ll)t... 

The coefficients of the polynomial are represented by a 17 digit 
binary number (1 0001 0000 0010 0001). The CRC method takes 
an entire block of data and divides it by this 17 bit number. The 
complement of the remainder, a two-byte value, is stored as the 
CRC. 

Every sector is given two cyclic redundancy checks. The first 
check (CRCl) is determined from the four-byte CHRN. When 
accessing sectors, CRCl verifies that the correct sector was 
located. The sector ID field ends with the two-byte error check. 

The ID and data fields are separated by a 22 byte gap. A sync 
field followed by address mark (AIAIAIFBH) initiate the dau 
field and signal the approach of data. The size of the data is based 
on the algorithm: 

data length • I28(N*«2) 

The sector length parameter (N) may take on values of 0-5 (128, 
256, 512, 1024, 2048, or 4096 bytes). However, values of N 
greater than 5 lead to chaos. For example, N = 6 (8192 bytes) 
requires a format that goes beyond one revolution of the disk. 
When a second pass to format the track is made, the ID field is 
overwritten and the sector is destroyed. 

The data field ends with the second cyclic redundancy check 
(CRC2). For this error check, the entire data block is divided by 
the 17 bit polynomial, and the complement of the remainder 
stored as CRC2. Whenever data is read from a sector, the CRC is 
calculated and compared to the CRC2. An error message results if 
the two values disagree. 

Sectors are separated by gaps. The standard size is 80 bytes 
but gaps as small as two bytes may be used. A trade-off exists 
between disk capacity and gap size. If the size of a gap is reduced, 
the number of sectors can usually be increased. But remember, 
smaller gaps increase the possibility of overwriting the next sec- 
tor's ID field. This is most likely to be a problem when sectors are 
formatted on one machine and then written to by another. 



Viewing Control Information 

Now that you are familiar with the structure of tracks and 
sectors, 1 will show you how to display diskette control infor- 
mation. The method, which 1 call sector overlap, allows you to 
look at the preliminary, sector components, and aps. You will 
need the DOS DEBUG utility and a scratch diskette. 



Address 

0:525H 
0:526H 
0:529H 
0:52AH 



Defines 



sector size (Nl 
sectors/track 
sector gap 
format fill 



Default value 

N-2 (512 bytes) 

9 

50H (80 bytes) 

F6H 



Table 1. The four track parameters 



A formatted track is defined by four track (see Table 1) plus 
four sector (CHRN) parameters. The track parameters are stored 
in the diskette parameter table (address 0:522 -0:52CH) during the 
computer start-up. When a track is formatted, the "track" N 
determines the number of bytes written to each sector. However, 
once the format is complete, the "sector" N takes over and 
regulates the number of bytes read or written. If the "sector" N 
exceeds the "track" N, diskette control information can be 
read. Our strategy is to format a track with nine standard 

sectors (N = 2), but assign a CHRN to the fifth sector correspon- 
ding to 4096 bytes (N = 5). Figure 4 lists the assembly language 
program to carry out such a format to track 01 /side 00. Load the 
DEBUG utility and place your scratch diskette in drive A. Enter 
the program (omit comments) by means of the assemble com- 
mand (AlOOH) and then execute. 



A>OEBUG 

-AlOO (enter prograai) 

-G 

To read Sector 5 Into the buffer area beginning at offset 
lOOOH, enter the follo«ing mod I f 1 cat I on» to the format 
program: 

-E 105 

DS:0I05 05.02 

-E 107 

DS:0I07 09.01 

-E 106 
DS:010e 01.05 

-em 

DS:0111 17.00 01.10 



OS:0100 


MOV 


AH, 00 




;RESET DISK CONTROLLER 




0S:0102 


IHT 


13 




;BIOS DISK I/O 




DS:0104 


MOV 


AH, 05 




; FORMAT TRACK 




0S:OI06 


MOV 


AL,09 




;9 SECTORS 




0S:0108 


MOV 


CH.OI 




;STARTiHG AT TRACK 01 




DS:OIOA 


MOV 


a, 01 




; " SECTOR 01 




0S:01X 


MOV 


OH.OO 




; • HEAD 00 




DS:010e 


MOV 


OL.OO 




; " DRIVE A 




OS:0110 


MOV 


BX,0117 




;POINT TO CHRN 




DS:0113 


INT 


13 




;BI03 DISK I/O 




OS:0115 


INT 


20 




jRETVJRN TO DOS 




DS:0U7 


oe 


01 00 01 


02 


■,a«H ENTRIES 




DS:01IB 


oe 


01 00 02 


02 






OS:OnF 


cs 


01 00 03 


02 






DS:0123 


oe 


01 00 04 


02 






DS:0127 


oe 


01 00 05 


05 


; LARGE SECTOR N 




DS:012B 


oe 


01 00 06 


02 






0S:012F 


OB 


01 00 07 


02 






03:0133 


oe 


01 00 08 


02 






03:0137 


oe 


01 00 09 


02 






Figure 4 


Assembly language 


program to format track with 






over 1 app i ng 


sectors 





The program to read Sector 5 appears in Figure 5. Before you at- 
tempt to read Sector 5, you must change the data length 
parameter (address 0O0O:O525H) from N = 2 to N = 5. 



-e 0:525 

0000:0523 

-G 



02.05 
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^i u:iX 


MOV 


AH, 00 


.-RESET DISK CONTROLLER 


Oi :■-. 


INT 


13 


;BIOS DISK I/O 


i i i v-4 


MOV 


AH, 02 


;READ TRACK 


t i c' Jf 


MOV 


AL,05 


;1 SECTOR 


1. i . 1 Oe 


MOV 


CH,01 


; STARTING AT TRACK 01 


iJi.. iA 


MOV 


CL.Ol 


; " SECTOR 05 


li.C'OC 


MOV 


OH, 00 


; " HEAD 00 


;. ■- L : Jk 


MOV 


OL,00 


DRIVE A 


.^b .■ 'L 


MOV 


BX,1000 


; PC INT TO BUFFER AREA 


DS C- ' ! 


INT 


13 


;8I0S DISK I/O 


:.'b:c- ■' 


INT 


20 


;RETURN TO DOS 


( 1 Ju'-f •) 


Assembly language 


program to read Sector 5 



The read operation stores 4096 bytes into the buffer area at of- 
fsets 1000- 1 FFFH. You can display these locations with the dump 
command 

-O 1000 (displays offsets 1000-107FH) 

Startmg with the data in Sector 5 (512 bytes of F6H), you can 
view 40% consecutive diskette storage locations. Table 2 offers a 
summary of these locations (offsets 1000-lFFFH). 



Offset 

1000-lFFFH 

1200-1201 

1202-1251 

I252-125D 

125C-1261 

1262-1265 

1266-1267 

I 268-1 270 

127E-1289 

128A-128D 

128E-148D 

148E-148F 

1490-1C39 

1C3A-1D65 

ID66-1DF8 

1DF9-1FFF 



Description 



512 bytes F6H (sector 5) 

CRC2 

sector gap 

ID sync field (sector 6 begins) 

ID address mark 

CHRN 

CRCl 

field separator 

data sync field 

data address mark 

512 bytes F6H 

CRC2 (sector 6 ends) 

sectors 7-9 

4EH to end of track. 

track pre! Iminary 

sector 1 



Table 2. Summary of 4096 consecutive diskette locations 



Sector 5 required a "long" read that goes beyond the end of 
the track. The preliminary is read during a second pass of the 
track, and there is a one in eight chance of reading these bits in the 
proper synchronization. 1 had to make several runs before syn- 
chronization was correct. Figure 6 shows the results of an unsuc- 
cessful attempt preliminary. In this figure, the preliminary is read 
one bit too early and the initial 80 bytes (offsets 1D66-IDB6H) 
appear as 27H. Reading a series of hexadecimal 4E (0100 1110) 
one bit out of synchronization gives: 



4E4E4E4EH » 0100 1110 0100 1110 0100 1110 0100 1110 

27H 27H 27H 

The preliminary address nark Is also read one bit early and 
appears as 616161 7EH Instead of C2C2C2FCH. 



C2C2C2FCH > 


1100 


0010 


1100 0010 1100 0010 


1111 


1100 






61H 




6IH 


6IH 




7EH 




-0 1D66, 


1DF6 
















OS: 1060 








A7 27-27 


27 27 27 


27 


27 27 


27 


DS:1D70 


27 27 


27 27 


27 27 


27 27-27 


27 27 27 


77 


27 27 


27 


OS: 1080 


27 27 


27 27 


27 27 


27 27-27 


27 27 27 


77 


27 27 


27 


0S:1D90 


27 27 


27 27 


27 27 


27 27-27 


27 27 27 


27 


27 27 


27 


DS:10A0 


27 27 


27 27 


27 27 


27 27-27 


27 27 27 


77 


27 27 


27 


DS:IDeO 


27 27 


27 27 


27 27 


27 00-00 


00 00 00 


00 


00 00 


00 


DS:10C0 


00 00 


00 50 


DO DO 


FF 00-80 


00 81 5E 


60 


A7 27 


27 


OS:IOOO 


27 27 


27 27 


27 27 


27 27-27 


27 27 27 


27 


27 27 


27 


OS: 1 DEO 


27 27 


27 27 


27 27 


27 27-27 


27 27 27 


27 


27 27 


27 


DS:1DF0 


27 27 


27 27 


27 27 


27 










Figure 6 


. Track preliminary (one bit out of 


sync) 





Run the format program again to help remedy synchronization 
problems. If you are unsuccessful after a few attempts, format a 



different track or diskette. 

A track is considered unformatted when the preliminary is 
overwritten. If you should write 4096 bytes to Sector 5, the 
preliminary and Sectors 1, 6, 7, 8, and 9 are destroyed. However, 
you will still be able to read/ write Sectors 2, 3, and 4. 

Data Capacity 

I conclude this article by examining the effect diskette con- 
trol information has on data capacity. How many bytes of data 
can the diskette accommodate? Which of the six allowed sector 
sizes leads to the maximum storage of data? Before reporting the 
results of my investigation, I'll show you how to predict data 
capacity. 

I calculate the total track capacity, including diskette control 
information, at 6253 bytes. Here is the breakdown for the 360K 
format: 

146 bytes track Preliminary 
4608 data (9*512) 
558 sector control Information (9*62) 
640 gap betoeen sectors (8*80) 
301 to end of track 

The percent utilization of diskette space comes in at 73.707o 
(4608/6253) for the 360K format. Let's determine the maximum 
number of sectors (512 byte size) possible for a single track. For 
ten sectors, the number of bytes required are: 



146 bytes 
5120 
620 
720 


track Prel Iminary 

data (10*512) 

sector control Information (10*62) 

gap betKoen sectors (9*80) 


6606 bytes 





To accommodate the ten sectors, 353 bytes must be eliminated 
from the track. The preliminary (146 bytes) and the sector control 
information (620 bytes) cannot be altered. If the track limit is to 
stay within 6253 bytes, the gap between sectors must not exceed 
40 bytes. For ten sectors per track, the diskette capacity is com- 
puted as: 



capacity 



(disk sides) (tracks/side) (sectors/track) (size) 



1024 



(2) (40) (10) (512) 



Any attempt to format a track with more than ten sectors of this 
size, regardless of gap size, is doomed to fail. The eleventh sector 
will overwrite the preliminary and the first sector of the track. 

To facilitate my investigation of data capacity, I relied on the 
Disk Explorer. This handy utility, distributed by Quaid Software 
Limited, makes it easy to format a track. From the "edit format" 
screen, you need only define the four track plus four sector 



Edit Format 

drive: track. head a:0.0 



N SC 


GPL kind 


2 10 


2 246 


key 


purpose 


se 1 ect field 


PgUp 


ed i t coanand 


PgDn 


edit id's 


Esc 


return 


+ 


change field 


F5 


format track 


enter 


read sector 



C H 


R 


N 


1 




2 


1 




2 


1 




2 


1 




2 


1 




2 


1 




2 


1 




2 


1 


8 


2 


1 


9 


2 


1 


10 


2 



SC flag 



Figure 7. The Disk Explorer (edit format screen) 
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Sector size 



128 

256 

512 

1024 

2048 

4096 



Dytes 



Sectors/Track 

32 
19 
10 

5 

2 

1 



Di skette Capacity 

320K 
380K 
400K 
400K 
320K 
320K 



Table 3. Data capacities for the six sector sizes 

parameters. To maximize the number of sectors per track, I set 
the sector gap length at two bytes. Figure 7 illustrates the screen 
that I selected to format ten sectors to track 01 /side 00. The flags 
(none showing) signal when sectors are formatted unsuccessfully. 
A summary of my results may be seen in Table 3. The Disk 
Explorer permits a maximum of 24 sectors per track and the first 
format (32 sectors) was generated with a program similar to the 
one in Figure 4. The other five formats were produced with the 
Disk Explorer. For the six formats listed, I verified that all sectors 
could be read. ■ 



Reader's Feedback 



(Continued from page 35) 

STD & MIDI, and am targeting 'elec- 
tronic musician', etc, for MIDI/Audio 
stuff. 

What I like (at this time in my work and 
while in school): (1) Review the languages 
(i.e. C, Pascal, True Basic, Fortran, 
assembly) for the PC & RSI. (2) A/D 
D/A — hardware, software, plotting on 
dot and plotter machines for the PC. (3) 
How about AD/DA for something like C- 
64? This can free up my IBM when I'm 
doing 24 hour monitoring and 8-bit is OK. 
(4) Video/audio manipulation via 
digitization. 

At home I use: (1) Xerox 820-1 with two 
5 Vt " DSQD and 2 8' SSSD, currently up- 
dating to IM RAM and QP/M OS. (2) 
Apple ][+ with 6MHz Z80 card. (3) WUl 
also soon start playing with a surplus 
Morrow MD-2 board recently acquired. 

At work I do machine control ap- 
plications in Forth on STD bus Z80s, and 
also use a MicroMint SB- 180. 

I am interested in Forth, real-time 
machine control applications; beyond- 
beginner treatment of algorithms, har- 
dware, and topics related to above listed 
interests; newer, non-PC, inexpensive 
processing and control engines — like 
the SB-180 and Hawthorne Technolog's 
Tiny Giant/K-OS 

I would like to see articles on hard disk 
drives and their controllers. How to 
trouble shoot them, set them up, how to 
program the controllers, what is standard 
and what is not for CP/M, MS DOS, 
Kaypro, IBM, SCSI, SASI. 

I use a IBM XT at work, and have an 
Osborne 1 at home. This coming winter I 



plan on using some type of 
microprocessor to control and operate a 
model railroad. I/O devices are of interest 
tome. 

I use a Corona (CORDATA) MS DOS 
"clone". I'm interested in coprocessor 
boards (Z80, Hitachi HD64180, or 
Motorola 68XXX) for MS DOS com- 
puters, and help in fmding any OEM's 
that sell completely assembled systems 
using the Hitachi CPU — I am definitley 
not a "Hacker" — but am very in- 
terested in the "8-bit revolution." 

I would like articles on: (1) 
Design/Construction articles: a) 68000 
based machines and interfaces to 
peripherals such as floppy drives, hard 
disks, etc. b) use of computers in on-line, 
real time data acquisition, process con- 
trol, etc. c) image processing. (2) Software 
articles: a) cross-assembler for 6502, 
68000. b) image processing, file com- 
pression schemes, etc. c) AI programs that 
work! (i.e., neural nets), etc. 

I like the articles on Operating Systems 
and programming in C, Forth, and 
Pascal. The feedback loop control article 
was good. 

I use a SB180 with COMM 180. ZC- 
PR3, and the TERM-MITE STIOOO ter- 
minal controller. I'd like more articles like 
The Art of Source Code Generation and 
Disk Parameters. ■ 



Editor's Note: Send your comments on 
the above plus information on what 
you're doing and what you would like to 
see. Contact TCJ if these give you an idea 
for an article that you 'd like to write. 



Byte Magazine called it. 

CIARCIA'S 

SUPER 

SYSTEM 




The SB180 
Single Board Computer 

Featured on me cover ot Byte. Sept ' 985, 
the SB 1 30 lets CP/M users upgrade to a 
fast. 4" X 7 'h " sirigle board system 



6MHz 64180 CPU 

(Z80 instruction superset). 256K RAM. 

8K Monitor ROM with device test, disk 

format, read/write. 
Mini/Micro Floppy CoiKrollcr 

(1-4 drives. Single/Double Density. 

1 -2 sided. 40/77/80 track 3'h:' 5V4" 

and 8" drives). 
Measures 4' « TVi." with mounting holes 
One Centronics Printer Port 
Two RS232C Serial Ports 

(75-19,200 baud with console perl 

auto-baud rate select) 
ZCPR3 (CP/M 2.2/3 compatible) 
Multiple disk formats supported 
Menu-based system customization 



NPw Low _Pnces 



SB180-1 

SBI8O computer board w/256K 
bytes RAM and ROM monitor 
S299.00 

SB180-1-20 

same as above W/ZCPR3. ZRDOS 
and BIOS source $399.00 

COMM180-S 

SCSI interface $150.00 



Now Available 



TURBO MOOULA-2 $69.00 

TURBO MOOULA-2 with 
Qrapftlx Tootbox $89.00 



TO ORDER 
CALL TOLL FREE 

1 -800-635-3355 



TELEX 

643331 



For Technical Inlormalion or in CT. call 

1-203-871-6170 



Micromint, Inc. 

4 Park Street 

Vernon, CT 06066 
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Editor 



(Continued from page 2) 

Technical Support 

The computer industry, just like most 
other U.S. industries, is driven by sales. 
Consumable items such as food, soap, 
beer, and cigarettes which are used up 
must be purchased over and over again, so 
there is a lot of advertising money 
available for existing products which 
remain in production for a long time. 
Items such as computers, peripherals, and 
software tend to be used for a long time 
and only replaced with new revised 
products, so advertising money is 
available only for the newest products. 

This means that the people who want to 
learn more about the older computer 
systems and utility programs receive little 
support from advertisiers who only want 
to sell them something new and different. 
That's why the big glossy magazines con- 
centrate on the new products which their 
advertisers need to sell instead of suppor- 
ting the users who want to learn about 
what they already have. It also means that 
it is up to us to provide our own technical 
support by sharing our knowledge with 
each other. 

The lack of support is especially noticed 
by CP/M users, because very few vendors 
are advertising CP/M related products, 
and most magazines have abandoned 
CP/M because it is not generating enough 
advertising income. TCJ is here to serve 
your needs, but we can't do it if we don't 
hear from you — if you don't contribute 
anything, don't expect anything. 

Do You Need to Program? 

A writer in another publication stated 
that there is no longer a need to program 
because everything you need has already 
been written and is available as 
sharewhare or in the public domain. 

I agree that some people don't need to 
program, but I disagree with the blanket 
statement that no one has to program. It 
all depends on what you are doing with 
your computer, and anyone who makes 
such a statement has a very limited view 
based on what they see. Someone who 
only needs a wordprocessor, a spread- 
sheet, and an accounting program can 
probably get by without doing any 
programming as long as they are content 
to use the programs exactly as they are 
written using the exact hardware and 
peripherals for which they were 
designed — but heaven help them if they 
want to change printers or modify a 
report format. 



I am constantly writing short programs 
for the office. Most of them are for 
filtering text files, managing data files, or 
to drive the printers and the typesetter. 
These are primarily non-standard ap- 
phcations for which I doubt there are low 
cost programs readily available — and 
even if they are available it is probably 
faster to write them than it is to try to 
locate them. 



"... it is up to us to provide 
our own technical support 
by sharing our 

l(nowiedge ...." 



One example is a mailing list which we 
purchased in DIP format and needed to 
convert to MailMerge® format. It didn't 
take more than about a half hour to write 
a BDS C program to do the job. I have 
pieces of code for handling input and out- 
put files plus other common tasks, which 1 
read in with WordStar® and then 
modify. No, the code was not elegant, and 
it did not include good user interfacing, 
but the file was converted, and I may 
never use it again. I don't even know how 
long it took because it ran on another 
computer while I was doing something 
else. In this case it was much faster and 
easier to write the code than it would have 
been to search for something which might 
not even do exactly what I wanted. A 
couple hours after we received the DIP file 
on disk, we were using the data and I was 
doing something else. 

We did not know what format the data 
would be in, so the first thing I did was to 
dump a few pages to the printer in HEX 
and ASCII — then it was easy to figure 
out what the C program needed to do. 
This brings up another programming 
need, which is the problem of determining 
file structures for custom modifications. 
The first thing I do with any new file type 
is a dump in order to see how it's put 
together. We use the Condor® database 
system and while it works well in most 
cases, there are some instances where we 
need something different. Condor can ex- 
port the data to an ASCII file, but it is a 
bother always writing a file, so I just did a 
dump and then wrote a simple C program 



to extract (or even modify) the data in the 
main file. 

Some of the routines I write for inter- 
facing to our old Compugrap.iic typeset- 
ter are even more specialized and unlikely 
to be available elsewhere. The point of all 
this is that while many microcomputer 
users don't need to program, there are 
those of us who do need to program. I'll 
quote Hilton once more 'What's the use 
of having a computer if you can't make it 
do things YOUR way.' 

You wouldn't be reading TCJ if you 
didn't want to be able to program, but is it 
because you HAVE to program or 
because you WANT to program? Let's 
run a httle survey. Write and let us know 
if you could perform all your work or job 
functions without programming and you 
just program for fun, or if programming 
is a necessary part of the job. 

Multi-Tasking or Multi-Systems? 

While everyone else is pursuing multi- 
tasking and multi-user systems, I'm going 
the other way towards one user with 
multi-sytems. The cost of MS DOS clones 
and CP/M systems is so low (Xerox 820-11 
with 10 MB hard drive, CP/M 2.2, and 
WordStar, for $349 in BCE ad on page 
459 of the August Computer Shopper) 
that it is cheaper and easier to use another 
system for time consuming tasks such as 
database sorts or printer drivers. Why buy 
a printer buffer when you can get a com- 
plete system with hard drive for $350? 
You can set up the extra system so that 
you can send the data over RS-232 at 
19.2K baud (even between CP/M, 68000, 
and MS DOS systems, or you can move it 
on a disk). 

Now if I just had a master operating 
system which would manage multi- 
systems instead of multi-tasking. . . . 

The Coming Bloodbath There have not 
been many announcements about layoffs 
or business closings during the past six 
months, but all is not well in the industry. 
There are too many businesses trying to 
sell the same or equivalent products, and 
now that the demand is slacking off some 
of them are starting to hurt. We have 
talked to many supphers who are cutting 
back on their advertising. Has anyone else 
noticed that the July Byte is 200 pages less 
than the 1983 issue? At the same time the 
August issue of The Computer Shopper 
has grown from 322 pages to 512 pages in 
the last year! This indicates a major 
change in buying habits as computers 
become a commidity. It is difficult to un- 
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derstand how all those advertisers in 
Computer Shopper are selling enough to 
pay for the ads, and if they are selling that 
much, how is that affecting the computer 
stores? Also, how long will the market 
support sales of that magnitude before the 
demand is satisfied? 

I'm predicting that sales will decrease 
rapidly by October or November, and that 
the suppliers will try to hold out for the 
Christmas season, but that we'll see a lot 
of casulaties by February or March. It will 
be interesting to watch what happens in 
the computer magazine field as those 
businesses fail (remember that there is 
about a four month lead time for adver- 
tising). I've been plotting the page count 
for Byte since 1980, and Computer Shop- 
per since August 1986, and would be in- 
terested in seeing a chart of the page coun- 
ts for some of the other magazines for the 
past three or four years (if you keep your 
magazines, send the page counts for each 
month and year, and I'll publish a chart 
of the results). It is not impossible that we 
rr.ay see more computer magazines folding 
next year when their advertising revenue 
drops below an acceptable figure. 

Again, any feedback or comments on 
this will be appreciated. 



TCJ'SBBS — The Final Chapter 

One thing that McCain didn't mention 
in his article "Starting Your Own BBS" in 
the last issue is making sure that you have 
access to a reliable phone line. 

We are on a long rural line with such 
poor quality that we often have problems 
even with voice transmissions, and there 
are many times when we can not com- 
municate at 300 baud much less 1200 
baud. The final two weeks were so bad 
that we have finally had to discontinue the 
TCJ BBS because of transmission 
problems. While I blame most of the 
problem on our local lines, the quality is 
especially bad when the caller uses long 
distance services other than 
AT&T — even with voice calls I often 
have to have the caller redial using AT&T 
in order to be able to understand them. 
Perhaps this is because we are so far from 
a node for the alternative services. 

I'll try to make arrangements to place 
the program listings on another board in 
an area with better communications, and 
until then I'll supply listings on disk (as 
far as we are from most people, a disk is 
probably about as cheap as a phone call). 
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The purpose of this section is to bring 
important reference resource material to 
your attention, and to help you determine 
which items should be added to your 
library. We will attempt to concentrate on 
the less well known and unusual titles, 
especially those not already in wide 
distribution. 

We welcome your suggestions of titles 
which should be included, and also your 
requests for topics for which you can not 
find suitable reference material. 

The 68000: Principles & Programining 

by Leo J. Scanlon 

Published by Howard W. Sams & Co. 

1981, 5 '/: X 8 '/i", 237 pages 

This is a very useful book for someone 
switching over to the 680XX family, as it 
covers the background, chip hardware, 
and interfacing in addition to the instruc- 
tion set and routines. Originally published 
in 1981, the copy I have is the 1986 seven- 
th printing — a book which has been 
reprinted this many times must be selling 
well. 

The contents are as follows: 

• Chapter 1: An Introduction to the 
68000 Microprocessor — Overview of the 
68000; Internal Registers; Background on 
the Design of the 68000. 

• Chapter 2: Cross Macro Assembler 

— Assembler Statements; Assembly 
Language Instructions; Stand Alone 
Comments; Assembler Directives; Ex- 
pressions in the Operand Field; Con- 
ditional Assembly; Macros; Line Listing 
Format. 

• Chapter 3: The 68000 Instruction Set 

— Instruction Format in Memory; Ad- 
dressing Modes; Effective Addressing 
Mode Categories; Instruction Types; Data 
Movement Instructions; Integer Arith- 
metic Instructions; Locigal Instructions; 
Shift and Rotate Instructions; Bit 
Manipulation Instructions; Binary Coded 
Decimal (BCD) Instructions; Program 
Control Instructions; The Link and 
Unhnk Instructions; System Control In- 
structions. 



• Chapter 4: Mathematical Routines — 
Multiplication; Division; Division With 
Overflow; Square Root. 

• Chapter 5; Lists and Look Up Tables 
— Unordered Lists; A Simple Sorting 
Technique; Ordered Lists; Look Up 
Tables; Jump Tables. 

• Chapter 6: 68000 Microprocessor 
Chip Hardware — Clock, Power, and 
Ground Lines; The Data Bus and Address 
Bus; Function Code Signals; Asyn- 
chronous Control Signals; Synchronous 
Control Signals; Bus Arbitration Signals; 
System Control Signals; Interrupt Control 
Lines. 

• Chapter 7: Processing States, 
Privilege States, and Exceptions — 
Processing States; Privlege States; Excep- 
tions; Internally Generated Exceptions; 
Externally Generated Exceptions. 

• Chapter 8: Fundamentals of Inter- 
facing — 68000 Support Chips; 6800 Sup- 
port Chips; Interfacing a 6821 PI A to the 
68000. 

• Chapter 9: System Development — 
Motorola System Support Products; 
VME Bus; Other 68000 Related Products; 
68000 Software Support. 

The book provides a good overview of 
the 68000, with enough details to get you 
started. 1 like the fact that the chapter 
covering the instruction set is grouped by 
function with similar instructions 
together, instead of being discussed in 
alphabetical order. There are other 
reference books available with the 
alphabetical arrangement for use after 
you are familiar with the instructions. In 
addition to the chapter contents listed 
above, there are several appendices in- 
cluding Instruction Execution Times and 
a Summary of the 68000 Instruction Set. 
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(Continued from page 48) 
prints, having all wires labeled and 
marked, as assembled on site prints 
(showing changes or additions made at the 
last minute), make sure it has a modular 
design (affords for easy replacement of 
parts), doesn't contain one of a kind bus 
system (uses VME, STD, or Multibus car- 
ds). The last kicker was the memory 
upgrade of $3000 per 64K of memory, all 
because the original memory cards were 
not designed correctly. Component wise 
that is $300 worth of memory going for 
$3000, not a bad mark up. 

The point to consider here is watching 
your purchases for the near and long 
term. It may work great right now but 
what if it fails. The industries have been 
cutting back on using skilled personnel to 
service equipment, not supplying 
adequate documents to make your own 
servicing possible, and mostly expecting 
you to return the unit for repairs. This 
means you would need complete spares of 
every part used in the system, if you want 
to be up and running at all times. For GE 
systems that is $3000 (all boards cost 
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but these registered trademarks are 
the property of the respective com- 
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Microsoft. Wordstar; MicroPro Inter- 
national Corp. IBM-PC, XT. and AT; 
IBM Corporation. Z-80, Zilog. MT- 
BASIC, Softaid. Inc. Turbo Pascal. 
Borland International. 
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used in The Computer Journal they are 
acknowledged to be the property of the 
respective companies even if not 
specifically mentioned in each occuren- 
ce. 



about this) times 15, yes that is fifteen dif- 
ferent board types. When I say this is a 
poor design, I am serious. The power 
supply alone is 4 different boards (that 1 
know of), anyone of which can mess you 
up and can not be replaced with anything 
but the proper spare board. Most well 
designed systems, have a separate power 
supply, with a power monitoring circuit 
on the main CPU unit. Should the supply 
become flaky, the CPU sees it, shuts 
things down and you replace the unit with 
a spare or something like it. Down time on 
systems like that can be longer for me to 
get there than it is to fix them. Systems 
that don't have clear modular design can 
take longer to trouble shoot than repair. 

I just recently bought a new car and 
before I did, 1 checked Consumers Report 
and compared what I was interested in to 
other comparable units. Unfortunately, 
there is not a consumers report for in- 
dustrial controllers. We could also use one 
for regular computers as well. I have 
heard reports that IBM ATs are having 
hard disk failures as high as 60%. I don't 
know if this is true or not, but one just 
died the other day at work (less than 4 
months use) and several friends have gone 
through two or three drives before getting 
one to last. I also had a course in a 
training lab with 10 XTs using lOMeg 
hard drives, half of which sounded like 
gum ball machines (you could hear every 
bearing). Now these are real problems, 
but there is not a publication that tells you 
about these problems, except us. Let me 
know if you have validating information 
about systems or designs which are par- 
ticularly good or bad. Yup, that is 
"good" also, as I want to let you know 
what to buy as well. 

This is enough for one month, next time 
I should have some more projects fmished 
and be getting my new 68K system by 
then. I will be at the SOG again this year 
with Art. So till then, keep hacking. ■ 
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THE COMPUTER CORMER 

A Column by Bill KIbler 



The summer heat is here, and there is 
nothing lo do about it except to work har- 
der, i am Hearing completion of my 
master's program and am starting to con- 
sider other job prospects. What I am 
facing IS mostly an uphill battle however. 
Over ihe past year 1 have learned that the 
public, and management in particular, has 
a complete misconception of what is 
needed to teach computer skills. Some 
people equate it with learning to drive a 
car. I e^juaie the skills needed more closely 
to those of learning to fly. 

We take the skills we have learned using 
and servicing computers mostly for gran- 
ted. Those of us who are technically in- 
clined have little trouble handling the 
structure under which most computers 
operate. After usually a rather short 
period of time, we find we can master any 
new operations by relating it to other 
previous situations. The public at large 
unfortunately has none of these at- 
tributes. 

My last two classes have had a number 
of school teachers included in them, and I 
have been able to see first hand what an 
educated person, who has never seen a 
computer before, encounters in trying to 
learn the operations. The first problem is 
they can't type, and lots have never used a 
typewriter before. I don't understand how 
these people ever got the credential, but I 
guess typing services are making more 
money- than we think. These students get 
lost between DOS and program comman- 
ds very easily. The concepts of structure 
and dividing programs into logical 
operations is a hard concept for them to 
understand. 

The real battle for these people is with 
their schools. The schools expect these 
people, after one or two classes, to be able 
to teach other teachers and students. 
During the teaching they should also in- 
tegrate and write some creative 
educational programs. Because we work 
with programs and computers we under- 
stand the fallacy of this concept, unfor- 
tunately the school managers know so lit- 
tle about computers, they can't under- 
stand why these programs are not 
working. As i see it, untrained managers 
in education appear to be a large part of 



the problem. 

Managers in other fields can also be 
problems, especially if they were trained 
on mainframes. The manager of the com- 
puters services where I work has never 
used a microcomputer before. He told me 
once, he bought a C64 for his kids to play 
with, and that is his knowledge of micros. 
When it comes to training or purchasing 
of systems, this p)erson in charge has little 
idea of the needs of users or skills needed 
to use such systems. Now that 
management has seen the productivity of 
micros, they are buying them and 
promoting programmers to teach their 
use. I feel strongly that these managers 
will also blame the computer company 
when these poorly trained people destroy 
a couple months of data with one key 
stroke. 

I guess what I am getting at is the lack 
of appreciation for properly trained 
people in industry. I see this as one reason 
why the Japanese have been able to 
produce better products. They have 
valued training and skills very highly. We 
seem to have taken our education of late 
rather lightly. I know of lots of jobs where 
I work in which a large number of people 
have acquired their position by being 
related to the boss. Now don't get me 
wrong, I have nothing against properly 
qualified people that are related getting 
jobs over someone else who is not related. 
But what I have seen is people without 
skills and qualifications being given jobs 
because of relationships, or the cut of 
their clothes. It is my opinion that if we 
continue this practice it will not be long 
before countries other than Japan pass us 
up technically. 

In the Mail... 

On lighter subjects, I received the last 
copy of POOR MAN'S NETWORK, by 
Anderson Techno-Products. This is their 
version 2.00 and I was using version 1.0 
before this. I haven't had a chance to 
really test the things out yet, other than 
seeing that it worked. One thing he didn't 
do was make it clear that the addresses 
used in the overlay package need to be 
changed from the version 1.0 equates. I 



tried using mine from the other version 
apd they didn't work the first time. I 
changed the equates to the new addresses 
(10 hex higher, OFFSET now OFOO not 
OEOOhex) and it came up without any 
other problems. I still have problems with 
his BIGBOARDB overlay as I am using a 
XEROX 820II and have to use some other 
code. I have to use a MVI A, lOh and OUT 
PORTSTAT as part of each I/O 
(DRSANYEXT and DRSEXTRDY) 
before the IN PORTSTAT. The ratebaud 
(OE not OF) and stop bits (04 not OChex) 
were also changed. 

The neat thing about this version is the 
overlays for the RPM-PC program. This 
is an CP/M emulation program for the 
PC compatibles. Using this overlay should 
allow you to run the network on the PC 
and transfer CP/M and PC files back and 
forth. I use a modem program now, but 
could see the advantage of using this on 
the PC. I tried it with the Z80MU 
program from PCBlue #185, but still 
haven't found all the changes needed yet. 
I also have the Atari ST and its CP/M 
emulation program to try and see if we 
can make it run on them. I am looking 
forward to later when I can spend more 
time wringing out the program. He has 
also changed the file handling a bit, but I 
will cover that later too. 

The Saga Continues 

1 have had more rounds with the GE 
system at work lately, and hopefully have 
it fixed for now. We have spent over $30k 
just keeping this thing running. That is the 
cost of a new controller for the 5 AXIS 
lathe it is on. It really pays to check on 
replacement cost and technical support 
cost before one buys a system of any kind. 
The idea that these units will never break 
is just not true. After all this money we 
spent, we still don't have adequate spare 
parts, and there is going to be major 
problems when I leave later this year. The 
training on this system has really become 
specific, as it is just a one of a kind mon- 
ster. I have heard however that all GE 
systems are much the same. 

Some points to keep in mind when 
checking out other systems are: as built 

(Continued on page 47) 
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